Re: [tcpdump-workers] build failures on Solaris

2021-07-31 Thread Denis Ovsienko via tcpdump-workers
--- Begin Message ---
On Sat, 31 Jul 2021 14:55:32 -0700
Guy Harris  wrote:

[...]
> What version of CMake is being used, and how was it installed?
> 
> My Solaris 11 x86-64 virtual machine has CMake 2.8.6 in
> /usr/ccs/bin/cmake, installed from Sun^WOracle's Image Packaging
> System repositories, and I'm not seeing that behavior - the test
> programs are linked with -lpcap, as is tcpdump.

This issue reproduces on OpenCSW host unstable11s:

# CMake 3.14.3 (OpenCSW package)
# GCC 7.3.0

MATRIX_CC=gcc \
MATRIX_CMAKE=yes \
MATRIX_BUILD_LIBPCAP=no \
./build_matrix.sh 
[...]
$ /tmp/tcpdump_build_matrix.XXVrYyid/bin/tcpdump -D
/tmp/tcpdump_build_matrix.XXVrYyid/bin/tcpdump: illegal option -- D
tcpdump version 5.0.0-PRE-GIT
libpcap version unknown

As I have discovered just now, it does not reproduce on OpenCSW host
gcc211:

# CMake 3.14.3 (OpenCSW package)
# GCC 5.5.0

mkdir ~/bin
ln -s /opt/csw/bin/gmake ~/bin/make
PATH=~/bin:$PATH \
MATRIX_CC=gcc \
MATRIX_CMAKE=yes \
MATRIX_BUILD_LIBPCAP=no \
./build_matrix.sh
[...]
Tested setup count: 4

-- 
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

Re: [tcpdump-workers] build failures on Solaris

2021-07-31 Thread Guy Harris via tcpdump-workers
--- Begin Message ---
On Jul 31, 2021, at 3:37 AM, Denis Ovsienko via tcpdump-workers 
 wrote:

> # Solaris 11 with GCC #
> This is the opposite: the pre-compile libpcap feature test programs
> fail to link so all libpcap feature tests fail. However, libpcap is
> detected as available and the build process resorts to missing/ and
> produces a binary of tcpdump that is mostly functional:
> 
> $ /tmp/tcpdump_build_matrix.XX06MD.a/bin/tcpdump -D
> /tmp/tcpdump_build_matrix.XX06MD.a/bin/tcpdump: illegal option -- D

What version of CMake is being used, and how was it installed?

My Solaris 11 x86-64 virtual machine has CMake 2.8.6 in /usr/ccs/bin/cmake, 
installed from Sun^WOracle's Image Packaging System repositories, and I'm not 
seeing that behavior - the test programs are linked with -lpcap, as is tcpdump.
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers

[tcpdump-workers] build failures on Solaris

2021-07-31 Thread Denis Ovsienko via tcpdump-workers
--- Begin Message ---
On Sat, 24 Jul 2021 00:11:27 +0100
Denis Ovsienko via tcpdump-workers 
wrote:

> There are more related corner cases of varying severity,
> some of which I might have time to describe later.

So, as promised... Several warnings are now documented in the build
scripts (look for TCPSLICE_TAINTED=yes and TCPDUMP_TAINTED=yes).
Another problem that is briefly mentioned in a comment is tcpdump build
issues on Solaris specific to CMake and system libpcap. Hopefully my
notes have captured the details right.

# Solaris 10 with Sun C #
The pre-compile libpcap feature test programs link with the system
libpcap.so fine and run fine. The tcpdump binary links fine, but fails
to run:

$ /tmp/tcpdump_build_matrix.XXtwaqbh/bin/tcpdump --version
ld.so.1: tcpdump: fatal: libpcap.so.1: open failed: No such file or
directory

$ ldd /tmp/tcpdump_build_matrix.XXyKaiEo/bin/tcpdump

libpcap.so.1 =>  (file not found)
libsocket.so.1 =>/lib/libsocket.so.1
libnsl.so.1 =>   /lib/libnsl.so.1
libsmi.so.2 =>   (file not found)
libc.so.1 => /lib/libc.so.1
libmp.so.2 =>/lib/libmp.so.2
libmd.so.1 =>/lib/libmd.so.1
libscf.so.1 =>   /lib/libscf.so.1
libdoor.so.1 =>  /lib/libdoor.so.1
libuutil.so.1 => /lib/libuutil.so.1
libgen.so.1 =>   /lib/libgen.so.1
libm.so.2 => /lib/libm.so.2
/platform/SUNW,SPARC-Enterprise-T5220/lib/libc_psr.so.1
/platform/SUNW,SPARC-Enterprise-T5220/lib/libmd_psr.so.1

$ pcap-config --libs  
-L/opt/csw/lib -R/opt/csw/lib -lpcap

It looks like the test programs use the runpath, but tcpdump does not.

# Solaris 11 with GCC #
This is the opposite: the pre-compile libpcap feature test programs
fail to link so all libpcap feature tests fail. However, libpcap is
detected as available and the build process resorts to missing/ and
produces a binary of tcpdump that is mostly functional:

$ /tmp/tcpdump_build_matrix.XX06MD.a/bin/tcpdump -D
/tmp/tcpdump_build_matrix.XX06MD.a/bin/tcpdump: illegal option -- D

The problem seems to be that the feature test linking instead of using
the flags returned by pcap-config points exactly to the 32-bit version
of libpcap and fails:

$ pcap-config --libs
-L/usr/lib  -lpcap

/usr/bin/gcc
-DCHECK_FUNCTION_EXISTS=pcap_list_datalinks
CMakeFiles/cmTC_d38b1.dir/CheckFunctionExists.c.o  -o cmTC_d38b1
/usr/lib/libpcap.so

ld: fatal: file /usr/lib/libpcap.so: wrong ELF class: ELFCLASS32
collect2: error: ld returned 1 exit status

It likely has to do with these CMake variables:

TCPDUMP_LINK_LIBRARIES=/usr/lib/libpcap.so;socket;nsl
PCAP_LIBRARIES=/usr/lib/libpcap.so

Soon after that tcpdump linking does not force the 32-bit library and
works:

/usr/bin/gccCMakeFiles/tcpdump.dir/fptype.c.o
CMakeFiles/tcpdump.dir/tcpdump.c.o CMakeFiles/tcpdump.dir/bpf_dump.c.o
CMakeFiles/tcpdump.dir/missing/pcap_dump_ftell.c.o
CMakeFiles/tcpdump.dir/missing/datalinks.c.o
CMakeFiles/tcpdump.dir/missing/dlnames.c.o  -o tcpdump libnetdissect.a
-lpcap -lsocket -lnsl 

This automatically uses the 64-bit library (not in /usr/lib).

Autoconf build does not have the problem with feature tests because it
uses exactly what pcap-config has returned and lets the linker figure
the details out:

configure:6157: checking for pcap_findalldevs
configure:6157: gcc -o conftest -I/usr/inet6/include -g -O2
conftest.c -L/usr/lib  -lpcap -lsocket -lnsl  >&5
configure:6157: $? = 0

Sun C does not have the problem with feature tests: CMake invokes it
same way as GCC, but Sun C manages to produce feature test programs
that work as expected:

/opt/solarisstudio12.4/bin/suncc
-DCHECK_FUNCTION_EXISTS=pcap_list_datalinks
CMakeFiles/cmTC_97fb2.dir/CheckFunctionExists.c.o  -o cmTC_97fb2
/usr/lib/libpcap.so

This looks like some heuristics or a short-cut built into Sun C, but it
seems wrong to depend on it. Moreover, Sun C does not have to guess hard
for tcpdump linking because the flags are just correct:

/opt/solarisstudio12.4/bin/sunccCMakeFiles/tcpdump.dir/fptype.c.o
CMakeFiles/tcpdump.dir/tcpdump.c.o  -o tcpdump libnetdissect.a -lpcap
-lsocket -lnsl 

-- 
Denis Ovsienko
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers