On Wed, May 26, 2010 at 11:59:12AM -0700, Xin LI wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > On 2010/05/26 11:47, Garrett Cooper wrote: > > On Wed, May 26, 2010 at 11:28 AM, Rob Farmer <rfar...@predatorlabs.net> > > wrote: > >> On Tue, May 25, 2010 at 10:48 AM, Xin LI <delp...@freebsd.org> wrote: > >>> Author: delphij > >>> Date: Tue May 25 17:48:17 2010 > >>> New Revision: 208545 > >>> URL: http://svn.freebsd.org/changeset/base/208545 > >>> > >>> Log: > >>> libarchive now needs libcrypto and liblzma. > >>> > >>> Modified: > >>> head/release/amd64/boot_crunch.conf > >>> head/release/i386/boot_crunch.conf > >>> head/release/ia64/boot_crunch.conf > >>> head/release/pc98/boot_crunch.conf > >>> head/release/powerpc/boot_crunch.conf > >>> head/release/sparc64/boot_crunch.conf > >>> head/release/sun4v/boot_crunch.conf > >>> > >>> Modified: head/release/amd64/boot_crunch.conf > >>> ============================================================================== > >>> --- head/release/amd64/boot_crunch.conf Tue May 25 17:43:23 2010 > >>> (r208544) > >>> +++ head/release/amd64/boot_crunch.conf Tue May 25 17:48:17 2010 > >>> (r208545) > >>> @@ -39,6 +39,6 @@ progs ppp > >>> progs sysinstall > >>> progs usbconfig > >>> > >>> -libs -ll -ledit -lutil -lmd -lcrypt -lftpio -lz -lnetgraph > >>> +libs -ll -ledit -lutil -lmd -lcrypt -lcrypto -lftpio -lz -lnetgraph > >>> libs -ldialog -lncurses -ldisk -lcam -lsbuf -lufs -ldevinfo > >>> -libs -lbsdxml -larchive -lbz2 -lusb -ljail > >>> +libs -lbsdxml -larchive -lbz2 -llzma -lusb -ljail > >>> > >> > >> Does the order of the libs entries matter? Because I just tried on > >> i386 after this commit and I still get errors related to the sha1, > >> md5, etc. functions but it worked fine with -llzma -lcrypto at the end > >> of the last line. > > > > In theory it shouldn't because the linker should be smart enough > > to evaluate the dependencies and link everything properly, but our > > copy of binutils isn't intelligent enough to determine the appropriate > > order from what I've seen. > > Bad last minute change from me, I overlooked this :-/ > > Will a newer GNU ld solve this issue?
The behaviour is the standard for any unix linker I ever saw. Static libraries participate in symbol resolution only at the point they appear on the command line. Linker makes as many passes over the single library as needed to not have any unresolved symbols that can be resolved from the archive, then moves to the next. There are facilities that allow to change the behaviour, either by grouping the libraries, see --start-group switch, or by repeating the library several times at the proper place in the command line. Comments about "linker not being smart enough" are nonsense.
pgpqeFYWjryOY.pgp
Description: PGP signature
