tcpdump mailing list archives

Re: build failures on Solaris


From: Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 29 Sep 2021 21:21:59 +0100

--- Begin Message --- From: Denis Ovsienko <denis () ovsienko info>
Date: Wed, 29 Sep 2021 21:21:59 +0100
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

Current thread: