Re: Clue needed - failure trying to build from old sources

[Valery Ushakov <uwe%stderr.spb.ru@localhost>]

On Thu, Oct 10, 2013 at 05:27:56 -0700, Paul Goyette wrote:

> On Thu, 10 Oct 2013, Valery Ushakov wrote:
> 
> >On Wed, Oct 09, 2013 at 21:08:09 -0700, Paul Goyette wrote:
> 
> >>    /build/test/tools/x86_64/amd64/bin/x86_64--netbsd-gcc    \
> >>    --sysroot=/build/test/dest/amd64     -o npfctl \
> >>    npfctl.o npf_var.o npf_data.o npf_ncgen.o npf_build.o \
> >>    npf_extmod.o npf_disassemble.o npf_scan.o npf_parse.o \
> >>    -lnpf -lprop -lcrypto -lutil -ly       \
> >>    -Wl,-dynamic-linker=/libexec/ld.elf_so \
> >>    -Wl,-rpath,/lib -L=/lib
> >>    /lib/libcrypt.so.1: undefined reference to `__explicit_memset'
> >>
> >>Is it, for some reason, trying to use the host's installed copy of
> >>libcrypt rather than the one that was built earlier in $DESTDIR?  (I
> >>notice that it uses "-lcrypto" in the Makefile, but the error message
> >>refers to libcrypt - without the 'o').
> >
> >You can go to the obj dir - /build/test/obj/amd64/usr.sbin/npfctl and
> >run the above command there with --verbose &c added to see what's
> >going on.
> >
> >>So,
> >>
> >>1. Will adding "-l crypt" to npfctl's Makefile fix this?
> >
> >I don't think we require programs to manually specify transitive
> >closure of library dependencies.
> 
> Well, something is definitely broken!  As far as I can tell, the 
> explicit_memset() stuff was not even created until April time-frame, so 
> definitely does not exist in a 2013-03-01 build!  Yet, my build-host's 
> libcrypt gets included in the link (verified using ldd), and then we're 
> unable to resolve the symbol.
> 
> Explicitly adding '-l crypt' to npfctl's Makefile does allow the build 
> to continue and finish.

That's a hardly a fix if you don't understand why it works :)

Go to the objdir and run that command (without -lcrypt) with
-Wl,--verbose - you should see something like

libcrypt.so.1 needed /build/test/dest/amd64/lib/libcrypto.so
found libcrypt.so.1 at ....

-uwe