Current-Users archive

[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, 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' using

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

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

| Paul Goyette     | PGP Key fingerprint:     | E-mail addresses:       |
| Customer Service | FA29 0E3B 35AF E8AE 6651 | paul at    |
| Network Engineer | 0786 F758 55DE 53BA 7731 | pgoyette at |
| Kernel Developer |                          | pgoyette at  |

Home | Main Index | Thread Index | Old Index