svn commit: r208545 - in head/release: amd64 i386 ia64 pc98 powerpc sparc64 sun4v

[Garrett Cooper]

On Wed, May 26, 2010 at 11:59 AM, Xin LI <delphij at delphij.net> 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?

Juli informed me (off-list) that GNU ld _does_ in fact do this, but
only if you specify --start-group and --end-group in the linker
arguments (which she claimed required more RAM).

It might just be better to switch the linker library ordering as this
would fix the issue cleanly and quickly.

Thanks,
-Garrett