Hello I have try to compile tcpdump-4.5.1.tar.gz with libpcap-1.5.2.tar.gz
and receive following error:

checking for pcap-config... /usr/local/bin/pcap-config
checking for pcap_loop... no
configure: error: Report this to tcpdump-***@lists.tcpdump.org, and
include the
config.log file in your report. If you have downloaded libpcap from
tcpdump.org, and built it yourself, please also include the config.log
file from the libpcap source directory, the Makefile from the libpcap
source directory, and the output of the make process for libpcap, as
this could be a problem with the libpcap that was built, and we will
not be able to determine why this is happening, and thus will not be
able to fix it, without that information, as we have not been able to
reproduce this problem ourselves.


Libpccap was compiled with options:
***@beagleboard:/mnt/dcu/tcpdump-4.5.1/build# cat
../../libpcap-1.5.2/build/CONFIGURE_libpcap-1.5.2
#!/bin/sh

export LDFLAGS="-L/usr/lib"
export CPPFLAGS="-DARM_FPU_NONE=1 -DNO_UNALIGNED_ACCESS"
export CFLAGS="-I/usr/include -msoft-float -mtp=soft -Os"

../configure --enable-ipv6

Tcpdump was compiled with options:
***@beagleboard:/mnt/dcu/tcpdump-4.5.1/build# cat CONFIGURE_tcpdump-4.5.1
#!/bin/sh

export CPPFLAGS="-DARM_FPU_NONE=1 -DNO_UNALIGNED_ACCESS"
export LDFLAGS="-L/usr/lib"
export CFLAGS="-I/usr/include -msoft-float -mtp=soft -Os"

../configure --prefix=/mnt/dcu/tcpdump-4.5.1/build/binaries \
--with-crypto \
--with-smi \
--enable-ipv6

Makefile and full process of the libpcap compile and config.log of tcpdump
compiling are attached.
Unfortunately, it appears that the attachments were removed.

Michael, under what circumstances do attachments get removed from mail?

Evgheni, could you put those files online somewhere?
Hello Mr. Harris

you can download all files here
https://mega.co.nz/#!c0hh2JAI!RqkP-F5cb-yTGXtRe-FGTgiDdC4FiBOzmzccsGiL_wo

and I have attached those files to this email too.

And I want to add to this message that I have fixed this issue than used
previous stable version of libcap.

Please let me know if my email was informative to you.

With Best Regards, Evgheni.
...and, this time, the attachments *weren't* removed. Thanks.
It was, but could you also do, in the libpcap build directory:

nm -o libpcap.a | egrep lex

and send the output?

In addition:

checking build system type... armv7l-unknown-linux-gnueabi
checking host system type... armv7l-unknown-linux-gnueabi
checking target system type... armv7l-unknown-linux-gnueabi

Are you cross-compiling libpcap and tcpdump, or are you compiling them on the target machine?
Hello Mr. Harris

As I said before I have tried to build to different version of the libpcap
Also I want to pay your attention, that I have used native compilator,
because in the cross-compile I have received issue with enabling IPv6 in
the configure and I have not more time to find the cause of it.

This is my script for configure and make of libpcap library:
***@beagleboard:/mnt/dcu/libpcap-1.5.2/build# cat CONFIGURE_libpcap-1.5.2

#!/bin/sh
The tcpdump utility (last stable release 4.5.1) successfull works with
library libpcap (old stable release 1.4.0)
I use this for my system based on the ARM processor AM335x.

Please let me know if I can to help you in anything else.

With Best Regards, Evgheni.

P.S. Please note, that from the Saturday (Dec. 28) I'm going to Christmas
holidays and will not be able to help you till to Jan.13, 2014.
Hello Guy.
There is not one addition object file *pcap-dbus.o *in old stable version.

Also, I want to pay your attention on the one more fact about my system:
Right now, I have not possibility to run your commands every time on the my
current system with native compiler. There are a huge count of causes, but
may be I will reply on your emails with any delay in the future. So please
don't worry, if you will not see any reply from me, it's just emergency
case and I will try to reply you in the nearest future.

With Best Regards, Evgheni.
This command has not any output
WBR, Evgheni.
I.e., for whatever reason, there's no scanner code whatsoever!

So, what does

find /mnt/dcu/libpcap-1.5.2 -name 'scanner.*' -print

print, and what is the output of running

make distclean
./configure
make

in /mnt/dcu/libpcap-1.5.2/build? This *might* be a bug in doing "out-of-source-tree" builds (which is what you're doing - you're doing the build in a subdirectory of the source tree), where most stuff works, but building the output of {f}lex doesn't work.
Hello Guy.

You are absolutely right, I have compiled tcpdump with new libpcap library
I have used this trick with correct "source-tree" in different application,
like dnsmasq and anything else and I have not paId attention on it, because
the same hint with using "out-of-source-tree" was successfully applied to
old stable version of the libpcap library and for compilation of tcpdump
application.

I'm not sure if this issue is a bug, but I think will be better to change
your Makefile for change process of compilation more convenient for all
users (for me it's great, than I have compilation of the source code in the
independent directory tree and have binaries output in the another
independent directory).

Anyway, thank you for your help and Merry Christmas.

With Best Regards, Evgheni.
Well, as I indicated, it worked for me, so, to change Makefile.in or whatever, we'd need to know why it didn't work for you - and, to find that out, we'd need to know how scanner.o was built, to see why it doesn't define any symbols.

So, what does

find /mnt/dcu/libpcap-1.5.2 -name 'scanner.*' -print

print, and what is the output of running

make distclean
./configure
make

in /mnt/dcu/libpcap-1.5.2/build?
Hello Guy.

You are absolutely right in it.
I have tried again to compile libpcap 1.5.2 in the new directory and it was
done with success.
Thank you for your help and sorry for my fault.

Bye.
...and you were able to link tcpdump with the resulting libpcap?

If so, there were probably one or more bad .o files in the directory when you did the build, as your libpcap_configure file didn't show any compilation being done, just linking into a .so file and archiving into a .a file, and doing the "make distclean" cleaned that up.
Yes, I have compiled tcpdump with new path of the libpcap library without
any issue.
I think this issue was appeared because before to compile libpcap library I
have compiled several another packages already and may one of them has made
any changes in the my environment.

Hope it will not appear again.
...although I just tried that with a tarball from the Git trunk, on my OS X machine, and configuring and building in a "build" subdirectory worked, so it might be something different in your environment.
Hmmm, may be.

I will pay attention on this in the next time. ;)

You can close this issue.

Have a nice day, Evgheni.
Pretty much every single situation.
Please. http: for files, smtp for communications...
Hello Mr. Richardson

I have added link to files on the https server, I hope it's enough.
WBR, Evgheni
List,

last week I ran into this issue once but could not reproduce afterwards. My guess is this error is specific to non-straightforward builds of libpcap and/or leftovers across multiple build attempts.

It happened once as follows (please note Sabotage uses musl instead of glibc and libnetlink-tiny instead of libnetlink):

# (at a Linux host)
wget http://ftp.barfooze.de/pub/sabotage/sabotage-0.9.14-i386-66f57ca1-core.img.xz
unxz sabotage-0.9.14-i386-66f57ca1-core.img.xz
VBoxManage convertfromraw sabotage-0.9.14-i386-66f57ca1-core.img sabotage-0.9.14-i386-66f57ca1-core.vdi
VirtualBox & # add a new x86_64 VM using the .vdi disk image and powered it on

# (inside VM as root)
adduser tcpdump
passwd tcpdump

# (inside VM as tcpdump)
git clone git://github.com/the-tcpdump-group/libpcap.git
git clone git://github.com/the-tcpdump-group/tcpdump.git

Then I tried to compile libpcap without and with ("butch install autoconf" as root) autoconf, without and with .devel, without and with the following hacks:

---------------------------------------------------------------------------------
diff --git a/Makefile.in b/Makefile.in
index 31f3bdb..58f93d7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -744,4 +744,4 @@ releasetar:
rm -rf $$name

depend: $(GENSRC) $(GENHDR) bpf_filter.c
- $(MKDEP) -c $(CC) -m $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS) $(SRC)
+ $(MKDEP) -c $(CC) -m $(CFLAGS) $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS) $(SRC)
diff --git a/configure b/configure
index be87668..31a2dcc 100755
--- a/configure
+++ b/configure
@@ -5619,7 +5619,7 @@ if test "x$ac_cv_lib_nl_nl_socket_alloc" = xyes; then :
#
# Yes, we have libnl 2.x.
#
- LIBS="-lnl-genl -lnl $LIBS"
+ LIBS="-lnl $LIBS"

$as_echo "#define HAVE_LIBNL 1" >>confdefs.h

diff --git a/configure.in b/configure.in
index 2cae646..b53fb15 100644
--- a/configure.in
+++ b/configure.in
@@ -473,7 +473,7 @@ linux)
#
# Yes, we have libnl 2.x.
#
- LIBS="-lnl-genl -lnl $LIBS"
+ LIBS="-lnl $LIBS"
AC_DEFINE(HAVE_LIBNL,1,[if libnl exists])
AC_DEFINE(HAVE_LIBNL_2_x,1,[if libnl exists and is version 2.x])
AC_DEFINE(HAVE_LIBNL_NLE,1,[libnl has NLE_FAILURE])
---------------------------------------------------------------------------------

The configure call evolved over time and became the following:

CFLAGS=`-I/usr/include/libnl-tiny` \
LDFLAGS=`pkg-config --libs-only-L libnl-tiny` \
LIBS=`pkg-config --libs-only-l libnl-tiny` \
./configure

Eventually libpcap built OK (may be on 10th attempt), I ran ./configure in ../tcpdump and observed the "Report this to tcpdump-***@lists.tcpdump.org" boilerplate. A few more "make clean all" passes in libpcap directory later I checked again on the tcpdump side and the issue had vanished.
I don't know if that is related but a different way to trigger this failure on Solaris/SPARC is to compile libpcap in 64-bit mode and then to try compiling tcpdump in default 32-bit mode. The configure script will fail with the message and the log file will contain:

configure:5774: checking for local pcap library
configure:5983: result: ./../libpcap/libpcap.a
configure:5987: checking for pcap-config
configure:6005: found ./../libpcap/pcap-config
configure:6017: result: ./../libpcap/pcap-config
configure:6079: checking for pcap_loop
configure:6079: gcc -o conftest -DINET6 -I/usr/inet6/include -g -O2 conftest.c ./../libpcap/libpcap.a -lsocket -lnsl -lsocket -lnsl -lsmi >&5
ld: warning: file ./../libpcap/libpcap.a(pcap.o): wrong ELF class: ELFCLASS64
Undefined first referenced
symbol in file
pcap_loop /var/tmp//cc63sAMt.o
ld: fatal: symbol referencing errors. No output written to conftest
collect2: error: ld returned 1 exit status

--
Denis Ovsienko