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.
root@beagleboard:/mnt/libpcap-1.5.2/build# file > /mnt/libpcap-1.5.2/build/binaries/lib/libpcap.so.1.5.2 > /mnt/libpcap-1.5.2/build/binaries/lib/libpcap.so.1.5.2: ELF 32-bit LSB > shared object, ARM, EABI5 version 1 (SYSV), dynamically linked, > BuildID[sha1]=5cab06ddf6ba7e042de65048f5cfd969ed6536b1, not stripped Thank you for your help and sorry for my fault. Bye. On Tue, Dec 24, 2013 at 10:51 PM, Guy Harris <g...@alum.mit.edu> wrote: > > On Dec 24, 2013, at 12:46 PM, Evgheni Antropov <aid...@gmail.com> wrote: > > > 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). > > 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? > _______________________________________________ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
