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

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

On Wed, Oct 09, 2013 at 21:08:09 -0700, Paul Goyette wrote:

> I then attempt to run a 'build.sh build' using
> 
>       ./build.sh -T /build/test/tools/x86_64/amd64 \
>               -D /build/test/dest/amd64 \
>               -O /build/test/obj/amd64 \
>               -R /build/test/release \
>          -m amd64 -j1 tools
> 
> It runs for a while, and eventually fails with (manually line-wrapped 
> for improved readability)
> 
>       #      link  npfctl/npfctl

For "tools"?!


>       /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.


> 2. If I do that, do I also need to add ${LIBCRYPT} to DPADD?

BTW, shouldn't we use PROGDPLIBS instead of messing with DPADD
directly?  Note, that LIBFOO are defined as static libfoo.a.

PROGDPLIBS is not documented in bsd.README, but from quick RTFS it
looks analogous to documented LIBDPLIBS of bsd.lib.mk


-uwe