[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

packagers note: do not run ld directly



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


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]