[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Clue needed - failure trying to build from old sources
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.
> >>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 ....
Main Index |
Thread Index |