Re: Clue needed - failure trying to build from old sources
On Thu, 10 Oct 2013, Mindaugas Rasiukevicius wrote:
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').
So,
1. Will adding "-l crypt" to npfctl's Makefile fix this?
2. If I do that, do I also need to add ${LIBCRYPT} to DPADD?
3. Any other additional changes needed?
Seems like the same PR/47922, where joerg@ made a fix for ld(1).
Ah, kewl. Thanks!
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: Clue needed - failure trying to build from old sources
On Thu, Oct 10, 2013 at 04:43:12PM +0200, Martin Husemann wrote: > Wasn't there a bug to this effect in the toolchain with --sysroot= that > was later fixed in -current? PR 47922. Martin
Re: Clue needed - failure trying to build from old sources
Paul Goyette wrote:
> <...>
>
> # link npfctl/npfctl
> /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').
>
> So,
>
> 1. Will adding "-l crypt" to npfctl's Makefile fix this?
> 2. If I do that, do I also need to add ${LIBCRYPT} to DPADD?
> 3. Any other additional changes needed?
Seems like the same PR/47922, where joerg@ made a fix for ld(1).
--
Mindaugas
Re: Clue needed - failure trying to build from old sources
On Thu, Oct 10, 2013 at 06:40:51PM +0400, Valery Ushakov wrote: > > >> /build/test/tools/x86_64/amd64/bin/x86_64--netbsd-gcc\ > > >> --sysroot=/build/test/dest/amd64 -o npfctl \ > > 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 Wasn't there a bug to this effect in the toolchain with --sysroot= that was later fixed in -current? Martin
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. > > > >>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
Re: Clue needed - failure trying to build from old sources
On Thu, 10 Oct 2013, Valery Ushakov wrote:
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"?!
Sorry - copied the wrong line - it is for target "build"
/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.
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
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
Re: Clue needed - failure trying to build from old sources
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
Clue needed - failure trying to build from old sources
In an effort to track down my recent problems with the boot-loader, I'm
trying to rebuild earlier system (so I can do a binary search and find
out where the problem was introduced).
I checked out the old sources with
cvs checkout -D '2013-03-01' -l src
cvs update -D '2013-03-01' -P -d
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
/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').
So,
1. Will adding "-l crypt" to npfctl's Makefile fix this?
2. If I do that, do I also need to add ${LIBCRYPT} to DPADD?
3. Any other additional changes needed?
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at juniper.net |
| Kernel Developer | | pgoyette at netbsd.org |
-
