--- Begin Message ---
> For posterity, trying to CI the tcpdump-4.99 branch on illumos-amd64
> made it apparent that the same problem used to apply to illumos:
>
> ld: fatal: file /usr/lib/libpcap.so: wrong ELF class: ELFCLASS32
>
> $ find /usr/ -name pcap-config
> /usr/bin/pcap-config
> /usr/bin/amd64/pcap-config
>
> $ /usr/bin/pcap-config --libs
> -L/usr/lib -lpcap
>
> $ /usr/bin/amd64/pcap-config --libs
> -L/usr/lib/amd64 -Wl,-R,/usr/lib/amd64 -lpcap
Hmm, something didn't look right about this explanation. Eventually I
realized that the part above stands where and as described, but the
result was that "tcpdump -D" didn't work because the function is
depends upon was not detected.
The part below is from netbsd-mips64, where it was a consequence of a
GCC segfault during the function test. Which was unrelated to the 32/64
bit problem and didn't reproduce afterwards.
> This broke a number of tests, such as:
> -- Looking for pcap_open
> -- Looking for pcap_open - not found
>
> Consequently, several HAVE_xxxxx macros were erroneously unset, so
> tcpdump compiled its own substitute pcap_xxxxx functions and
> eventually clashed trying to link with libpcap.
ld: ../libpcap/libpcap.a(pcap.o): in function
`pcap_datalink_val_to_name':
pcap.c:(.text+0x3bd8): multiple definition of
`pcap_datalink_val_to_name';
libnetdissect.a(dlnames.o):dlnames.c:(.text+0x100): first defined here
> Cherry-picking a series of intertwined build system fixes from the
> master branch, including commit c39d40a ("On Solaris, for 64-bit
> builds, use the 64-bit pcap-config."), was sufficient to fix this.
--
Denis Ovsienko
--- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
