tcpdump mailing list archives
libpcap detection and linking in tcpdump
From: Denis Ovsienko via tcpdump-workers <tcpdump-workers () lists tcpdump org>
Date: Wed, 9 Sep 2020 17:07:25 +0100
--- Begin Message --- From: Denis Ovsienko <denis () ovsienko info>
Date: Wed, 9 Sep 2020 17:07:25 +0100
Hello list. Travis CI tcpdump builds have been failing for a while and I went to see why. It is easy to see that only the jobs that have "BUILD_LIBPCAP=yes CMAKE=yes" fail, for example [1], and the same jobs built well before, for example [2]. The tcpdump build process fails in these cases because CMake detects the presence and usability of particular libpcap elements before the compilation, but during the compilation the compiler is not finding these elements. For example: tcpdump.c:1251:19: error: ‘PCAP_OPENFLAG_PROMISCUOUS’ undeclared (first use in this function); did you mean ‘PCAP_WARNING_PROMISC_NOTSUP’? (The above compiles only when HAVE_PCAP_OPEN is defined.) I have spent some time trying to reproduce the amd64 Linux GCC case on my desktop. Initially I though it was a regression in libpcap because tcpdump had no meaningful changes between the successful and the failed jobs, and the job always clones the current master branch of libpcap. As it turned out, the reason for failure was not because of a change in tcpdump or libpcap, but because of a change in the Travis CI build environment, which is Ubuntu 18.04 and which recently started to include a pkg-config file in the libpcap package: libpcap (1.8.1-6ubuntu1.18.04.2) bionic; urgency=medium * Install pkg-config file for libpcap (LP: #1865501). - d/p/set-package-name-with-ac-init.patch: Set the PACKAGE_NAME variable using autoconf's AC_INIT macro, so that we can use it in the libpcap.pc.in file. - d/p/use-m4-macro-to-get-version.patch: Use an M4 macro to execute a "cat" command and obtain the version from the VERSION file. - d/p/install-pkg-config-file.patch: New patch from upstream, which creates a libpcap.pc.in file and adjusts the Makefile to install it. - d/libpcap0.8-dev.install: Install libpcap.pc pkg-config file. Thanks to Luca Boccassi for the Debian patch (Closes #922219). -- Sergio Durigan Junior <sergio.durigan () canonical com> Mon, 29 Jun 2020 17:49:04 -0400 If you examine the provided example jobs closely (the "Raw log" button returns the full output in plain text), here is the difference in CMake output when the job changes from good to bad: @@ -71,9 +71,8 @@ -- Check size of struct in6_addr - done -- Found PkgConfig: /usr/bin/pkg-config (found version "0.29.1") -- Checking for one of the modules 'libpcap' --- Found pcap-config -- Looking for pcap/pcap-inttypes.h --- Looking for pcap/pcap-inttypes.h - found +-- Looking for pcap/pcap-inttypes.h - not found -- Looking for pcap_list_datalinks -- Looking for pcap_list_datalinks - found -- Looking for pcap_free_datalinks The "Found pcap-config" message means that FindPCAP.cmake has not found libpcap by means of pkg-config, and the lack of the message means the pkg-config method worked. A few weeks ago Ubuntu 18.04 systems started to have the libpcap.pc file in the libpcap0.8-dev package, so on such a system "pkg-config --libs libpcap" now prints "-lpcap" and "pkg-config --cflags libpcap" prints an empty string, which makes sense. What does not make sense is that CMake seems to use non-pkg-config flags to tell if a specific feature is available, but uses pkg-config flags to compile and link the source, and when the system has one libpcap version installed as a package and another version that the user wants to build with, that very easily breaks (and even if it does not, the end result is not what the user was expecting). Here are my steps to reproduce: libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap libpcap$ make libpcap$ make install tcpdumpbuild$ cmake -DWITH_CRYPTO="yes" -DCMAKE_PREFIX_PATH=/tmp/libpcap -DCMAKE_INSTALL_PREFIX=/tmp/libpcap /path/to/tcpdump_git_clone The above fails if the package libpcap0.8-dev is installed. After removing the package the above works and tcpdump links with /tmp/libpcap/lib/libpcap.so.1 as expected. Clearly, there are cases where using pkg-config would be the right thing to do. But is seems wrong to try it always as the first choice. Perhaps it would be better to try pkg-config after the user-specified prefix did not result in a usable libpcap. Autoconf is not entirely consistent with CMake, in that it tries pkg-config before libpcap in the specified prefix directory too, but there are differences: * Before these two methods autoconf checks for libpcap in ../libpcap and links it statically if it is available. CMake does not do that. * If the above was not the case, the pkg-config method works in autoconf, so tcpdump is linked with the system libpcap. CMake build breaks in this case. * If the above was not the case and ./configure is given a prefix, it fails to find libpcap under that prefix. CMake gets that right. To me right now it looks as if the best first thing to do would be fixing pkg-config in CMake, that should recover Travis CI. Then the next best thing to do would be reordering the steps in both autoconf and CMake to try pkg-config after pcap-config, not before (that should prevent unexpected build results as libpcap.pc is propagating through Linux systems). After that it would be nice to have ../libpcap support in CMake and a full --prefix support in ./configure for full consistency. Does it make sense? 1: https://travis-ci.org/github/the-tcpdump-group/tcpdump/jobs/724717360 2: https://travis-ci.org/github/the-tcpdump-group/tcpdump/jobs/721706654 -- Denis Ovsienko
--- End Message ---
_______________________________________________ tcpdump-workers mailing list tcpdump-workers () lists tcpdump org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Current thread:
- libpcap detection and linking in tcpdump Denis Ovsienko via tcpdump-workers (Sep 09)