> Not questioning you, but I'm curious as to why exactly. I've seen this > in many projects over the years and while it always made me nervous, I > didn't really see any problems pop out. The most common problem historically is failing to include proper DT_NEEDED dependencies and symbol version bindings for other DSOs referred to by the DSO you're building. This means you've created a DSO which the system will happily load into a program that is actually using incompatible ABIs. Its calls will go to incompatible functions, and crash or misbehave in worse ways. At the packaging level, you won't have the correct automatic dependencies to that ordinarily let rpm/yum help you avoid installing things that could be broken in such ways when you run them. These are problems that won't show up any time soon in testing, but will come back to haunt your users later on, years from now. You also fail to include the magic crt* objects that may be necessary for initializers and finalizers (constructors and destructors) in your library to work right. You omit standard switches like --eh-frame-hdr and --hash-style=gnu, which may make your DSO perform poorly, or can even break exception handling. The recent new reason it's wrong is that you omit --build-id. This will be detected by debuginfo generation as a bug in your package. Thanks, Roland -- Fedora-maintainers mailing list Fedora-maintainers@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers -- Fedora-maintainers-readonly mailing list Fedora-maintainers-readonly@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-maintainers-readonly
