svn commit: r208545 - in head/release: amd64 i386 ia64 pc98
powerpc sparc64 sun4v
kostikbel at gmail.com
Wed May 26 19:15:07 UTC 2010
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 <rfarmer at predatorlabs.net> wrote:
> >> On Tue, May 25, 2010 at 10:48 AM, Xin LI <delphij at 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/svn-src-head/attachments/20100526/80672ec5/attachment.pgp
More information about the svn-src-head