Re: [tcpdump-workers] compilation status of current (2004-09-13)
On Sep 14, 2004, at 10:33 AM, Rick Jones wrote: well, with the link in place, i did the make dist clean then the configure then the make and did get the duplicate symbols. so, here is the config.log ... configure:8312: checking for local pcap library configure:8420: result: ./../libpcap/libpcap.a configure:8445: checking for pcap_list_datalinks configure:8495: cc -o conftest -g -L/usr/local/lib conftest.c ./../libpcap/libpcap.a -lnsl 5 /usr/ccs/bin/ld: (Warning) At least one PA 2.0 object file (conftest.o) was detected. The linked output may not run on a PA 1.x system. configure:8498: $? = 0 configure:8501: test -s conftest configure:8504: $? = 0 configure:8515: result: yes OK, so it thinks libpcap has pcap_list_datalinks()... configure:9005: checking if sockaddr struct has sa_len member configure:9029: cc -c -g conftest.c 5 cc: configure, line 9061: error 1588: sa_len undefined. cc: configure, line 9061: error 1531: Invalid member of struct or union. cc: configure, line 9061: error 1594: The sizeof operator cannot be applied to types with unknown size. configure:9032: $? = 1 configure: failed program was: | #line 9010 configure | /* confdefs.h. */ ... | #define HAVE_PCAP_LIST_DATALINKS 1 ...and it even defines HAVE_PCAP_LIST_DATALINKS as 1, meaning it *knows* it thinks that... ## - ## ## Output variables. ## ## - ## ... LIBOBJS=' strlcat$U.o strlcpy$U.o strsep$U.o' LIBS='-lcrypto ./../libpcap/libpcap.a -lnsl ' LOCALSRC='print-smb.c smbutil.c ' LTLIBOBJS=' strlcat$U.lo strlcpy$U.lo strsep$U.lo' ...and it even doesn't seem to think that it needs to use datalinks.o (which contains an implementation of pcap_list_datalinks() to use if libpcap doesn't have it). However, if it's getting a duplicate definition of pcap_list_datalinks(), it's apparently linking with it anyway. What is LIBOBJS defined as in the top-level Makefile? If it's defined as anything that includes datalinks.o, try doing a make distclean, re-running configure, and trying again. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13)
On Sep 14, 2004, at 4:38 PM, Rick Jones wrote: no datalinks.o: LOCALSRC = print-smb.c smbutil.c GENSRC = version.c LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o But you got duplicate symbol errors? What's the output of make? - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13)
Guy Harris wrote: On Sep 14, 2004, at 4:38 PM, Rick Jones wrote: no datalinks.o: LOCALSRC = print-smb.c smbutil.c GENSRC = version.c LIBOBJS = strlcat$U.o strlcpy$U.o strsep$U.o But you got duplicate symbol errors? What's the output of make? since that will be somewhat large, and since the list software doesn't especially like large messages or attachements, I'll send it to your individual email address. rick - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13) on HP-UX 11.11
On Sep 13, 2004, at 4:24 PM, Rick Jones wrote: For other nefarious porpoises I downloaded libpcap and tcpudmp currents on 2004-09-13 and did straight-up ./configure;make on HP-UX 11.11 (aka 11i v1) using the HP compiler. This system did not have the TOUR installed to get IPv6 functionality. The libpcap compiled cleanly. Just a couple warnings IIRC, and nothing that looked earthshattering. The compilation of tcpdump was clean. This is a big step from the last time I tried. The linking of tcpdump was not clean: ... /usr/ccs/bin/ld: Duplicate symbol pcap_list_datalinks in files datalinks.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_name in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_name_to_val in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_description in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) It appears that the configure script did not correctly determine that the libpcap with which to link tcpdump already had the functions in question, so it set up the Makefile to build tcpdump's fallback implementations of them. Could you send us the config.log file from the tcpdump directory? PS - I'm looking for worked examples of reconstructing a TCP stream (separate each way is fine/preferred) from a tcpdump format (binary) trace. Well, there's the Ethereal code for Follow TCP Stream, but it drags in a lot of the Ethereal framework. You might look at tcpflow: http://www.circlemud.org/~jelson/software/tcpflow/ - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] compilation status of current (2004-09-13) on HP-UX 11.11
/usr/ccs/bin/ld: Duplicate symbol pcap_list_datalinks in files datalinks.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_name in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_name_to_val in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) /usr/ccs/bin/ld: Duplicate symbol pcap_datalink_val_to_description in files dlnames.o and ./../libpcap/libpcap.a(pcap.o) It appears that the configure script did not correctly determine that the libpcap with which to link tcpdump already had the functions in question, so it set up the Makefile to build tcpdump's fallback implementations of them. That may be operator error on my part - the libpcap symlink may not have been there at configure time. Could you send us the config.log file from the tcpdump directory? if it still happens after a make distclean;./configure; make i'll send the config.log PS - I'm looking for worked examples of reconstructing a TCP stream (separate each way is fine/preferred) from a tcpdump format (binary) trace. Well, there's the Ethereal code for Follow TCP Stream, but it drags in a lot of the Ethereal framework. You might look at tcpflow: http://www.circlemud.org/~jelson/software/tcpflow/ thanks. the end goal is to look at NFS over TCP traffic where the traffic may have nfs messages split across segments, several in a segment, that sort of thing. rick jones - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
