An easy mistake sometimes made in packages' build setup is to run ld directly rather than via gcc, e.g. when creating a shared library. It is always wrong to run ld directly when a linking user-mode executable or shared library. This rule is not Fedora-specific, so be sure to get the makefile fixes upstream. e.g. a makefile line: $(LD) -shared -o $@ $(objs) should be: $(CC) -shared -o $@ $(objs) Best practice is to use consistently the flags otherwise passed to the compiler, and also use LDFLAGS, i.e.: $(CC) $(CFLAGS) $(LDFLAGS) -shared -o $@ $(objs) If you use higher-level tools rather than writing these command lines by hand in makefiles or elsewhere, those tools should already be doing the right thing. For DSOs especially, linking the wrong way causes several subtle bugs though things may work correctly when you test them right after the build. Letting the compiler run the linker with the correct details is always the right way to be sure you get a kosher binary. In Fedora 8 (and rawhide as of very soon), a binary built incorrectly in this way is likely to be detected at rpm build time and prevent your rpm being built. You may see errors like: *** ERROR: No build ID note found in /var/tmp/buildroot/.../some-binary The most likely cause of that error is an improper linking command used to create "some-binary". If your package runs ld directly for the final link to create an executable or DSO, and it seems more complex than the simple mistakes I've described, please post here for advice. The initial presumption should be that the use of ld is probably wrong. If there is a special need, there is probably a better way to address it. Thanks, Roland -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
