Summary: | net-analyzer/nmap - nping/configure automagically pulls in libnl when it should not | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Jeroen Roovers (RETIRED) <jer> |
Component: | Current packages | Assignee: | Gentoo Netmon project <netmon> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | floppym |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 480474 | ||
Attachments: |
net-analyzer:nmap-6.25-r1:20141114-131752.log
nping/config.log |
Description
Jeroen Roovers (RETIRED)
2014-11-14 14:46:20 UTC
Looks like a failure to detect libpcap when cross-compiling. Is this a regression from net-analyzer/nmap-6.25? I don't see how any of the changes I made in 6.25-r1 would cause this. Sorry, nevermind the cross-compiling part; the weird looking CHOST on hppa confused me for a moment. Also, I cannot reproduce this on my ~amd64 system. -r0 fails the same way. > === configuring in nping (/dev/shm/portage/net-analyzer/nmap-6.25-r1/work/nmap-6.25/nping)
> configure: running /bin/sh ./configure --disable-option-checking '--prefix=/usr' '--build=hppa2.0-unknown-linux-gnu' '--host=hppa2.0-unknown-linux-gnu' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib' '--libdir=/usr/lib' '--enable-ipv6' '--enable-nls' '--with-zenmap' '--with-liblua' '--with-ncat' '--with-ndiff' '--with-nmap-update' '--with-nping' '--with-openssl' '--with-libdnet=included' 'build_alias=hppa2.0-unknown-linux-gnu' 'host_alias=hppa2.0-unknown-linux-gnu' 'CFLAGS=-mschedule=8000 -march=2.0 -ggdb -Wall -O2 -pipe -Wno-comment' 'LDFLAGS=-Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed' 'CXXFLAGS=-mschedule=8000 -march=2.0 -ggdb -Wall -O2 -pipe' 'PYTHON=/usr/bin/python2.7' --cache-file=/dev/null --srcdir=.
> ...
> checking if libpcap is suitable... no
Should have a look at nping/config.log.
Created attachment 389572 [details]
nping/config.log
configure:5256: hppa2.0-unknown-linux-gnu-gcc -o conftest -mschedule=8000 -march=2.0 -ggdb -Wall -O2 -pipe -Wno-comment -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed conftest.c -lnl -ldl -lpcap >&5 configure:5256: $? = 0 configure:5256: ./conftest ./configure: line 1644: 4217 Segmentation fault ./conftest$ac_exeext configure:5256: $? = 139 configure: program exited with status 139 I'm not sure what would cause that segfault... maybe a bad symbol table in libpcap? I see the same problem with 6.47 now. I'm beginning to think it's a local thing. gdb> bt full #0 genl_unregister (ops=0xf9b211ac <genl_ctrl_ops>) at genl/mngt.c:217 No locals. #1 0xfac0b05c in _dl_fini () at dl-fini.c:252 array = <optimized out> i = 0x0 nmaps = 0xa nloaded = <optimized out> i = 0x3 l = 0xfaeffd60 ns = 0x0 maps = 0xfaf034d0 maps_size = <optimized out> do_audit = 0x0 __PRETTY_FUNCTION__ = "_dl_fini" #2 0xfa4373d8 in __run_exit_handlers (status=0x0, listp=0xfa5661a8 <__exit_funcs>, run_list_atexit=run_list_atexit@entry=0x1) at exit.c:82 atfct = <optimized out> onfct = <optimized out> cxafct = <optimized out> f = <optimized out> #3 0xfa437410 in __GI_exit (status=<optimized out>) at exit.c:104 No locals. #4 0xfa41c9a0 in __libc_start_main (main=<error reading variable: can't compute CFA for this frame>, argc=<error reading variable: can't compute CFA for this frame>, argv=<error reading variable: can't compute CFA for this frame>, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=<optimized out>) at libc-start.c:319 result = <optimized out> unwind_buf = <error reading variable unwind_buf (can't compute CFA for this frame)> not_first_call = <optimized out> #5 0x000105e8 in _start () No symbol table info available. I think this is an old problem with libdl on HPPA. I'm sure I had a bug report about this. (In reply to Jeroen Roovers from comment #9) > gdb> bt full > #0 genl_unregister (ops=0xf9b211ac <genl_ctrl_ops>) at genl/mngt.c:217 Oh wait. That's dev-libs/libnl:1. In nping/configure.ac: # libpcap can require libnl AC_SEARCH_LIBS(nl_handle_alloc, nl) That's naughty because we don't cover that and it randomly chooses libnl:1 over libnl:3. That's libnl:1.1 actually. What happens is that libpcap links against libnl-3 and then nping/configure.ac mixes in libnl.a. See also bug #469176. Fixed without revision bump. Nice find! |