Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message ---
On Wed, Sep 9, 2020 at 12:08 PM Denis Ovsienko via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> wrote:
> 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
These jobs are still failing, but now for a different reason. The build
succeeds, but the tests fail - the tests that require the new libpcap.
However, if you augment TESTrun to print the version, it says
1.11.0-PRE-GIT but the tests that need the new libpcap still fail. I can
not find anything that changes LD_LIBRARY_PATH, or anything, but shortly
after running
print "Running tests from ${testsdir}\n";
print "using ${TCPDUMP}\n";
system "${TCPDUMP} --version";
we run
$r = system "$TCPDUMP -# -n -r $input $options >tests/NEW/${outputbase}
2>${rawstderrlog}";
and that uses the wrong libpcap.
I am at loose ends as to how to debug further - a sample log from my
attempt to see what's going on is
https://api.travis-ci.com/v3/job/468210839/log.txt - the diffs in that run
are very simple (and the env. variable one is probably
incorrect/unnecessary) -
https://github.com/the-tcpdump-group/tcpdump/compare/master...fenner:cmake-pcap
Bill
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On 07/01/2021 18:35, Bill Fenner via tcpdump-workers wrote: > These jobs are still failing, but now for a different reason. The build > succeeds, but the tests fail - the tests that require the new libpcap. > However, if you augment TESTrun to print the version, it says > 1.11.0-PRE-GIT but the tests that need the new libpcap still fail. My hypothesis is that, with the cmake build, for some reason, tcpdump linked to the 1.11.0-PRE-GIT local library was built with include files for the system libpcap not the local libpcap ones, thus DLT_DSA_TAG_BRCM and some other macros (which exist only in the new libpcap) are undefined (hence the UNSUPPORTED outputs). '-I' configuration problem? (The autoconf build add in the Makefile: INCLS = -I. -I../libpcap) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers wrote: > These jobs are still failing, but now for a different reason. Part of the problem is that pkg-config wasn't finding the locally-installed libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point to /tmp/lib/pkgconfig. We're now doing that, and I re-enabled those jobs; so far, the GCC builds on Linux seem to be working for BUILD_LIBPCAP=yes CMAKE=yes.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message ---
On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers
wrote:
> 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.
It makes sense if you want to build with the *system* libpcap.
It does *not* make sense if you want to build with the libpcap that was built,
and installed under /tmp, in the Travis build. For *that*, you'd want
"pkg-config --libs libpcap" to print "-L/tmp/lib -lpcap" and you'd want
pkg-config --cflags libpcap" to print "-I /tmp/include".
That's because it's finding the libpcap.pc file in the libpcap0.8-dev package,
not the one in /tmp/lib/pkgconfig; the latter one should do what we want.
I changed .travis.yml to run CMake with PKG_CONFIG_PATH=/tmp/lib/pkgconfig,
which appears to make it find the right .pc file and thus to find the right
libpcap.
> What does not make sense is that CMake seems to use non-pkg-config
> flags to tell if a specific feature is available,
It *should* be using the pkg-config flags - the code that tests for features
just does
#
# libpcap/WinPcap/Npcap.
# First, find it.
#
find_package(PCAP REQUIRED)
include_directories(${PCAP_INCLUDE_DIRS})
cmake_push_check_state()
#
# Now check headers.
#
set(CMAKE_REQUIRED_INCLUDES ${PCAP_INCLUDE_DIRS})
#
# Check whether we have pcap/pcap-inttypes.h.
# If we do, we use that to get the C99 types defined.
#
check_include_file(pcap/pcap-inttypes.h HAVE_PCAP_PCAP_INTTYPES_H)
#
# Check for various functions in libpcap/WinPcap/Npcap.
#
cmake_push_check_state()
set(CMAKE_REQUIRED_LIBRARIES ${PCAP_LIBRARIES})
#
# Check for "pcap_list_datalinks()" and use a substitute version if
# it's not present. If it is present, check for
"pcap_free_datalinks()";
# if it's not present, we don't replace it for now. (We could do so
# on UN*X, but not on Windows, where hilarity ensues if a program
# built with one version of the MSVC support library tries to free
# something allocated by a library built with another version of
# the MSVC support library.)
#
check_function_exists(pcap_list_datalinks HAVE_PCAP_LIST_DATALINKS)
...
cmake_pop_check_state()
which doesn't care whether PCAP_INCLUDE_DIRS and PCAP_LIBRARIES were set from
pkg-config or pcap-config or manually poking the system.
> but uses pkg-config
> flags to compile and link the source,
*However*, the CMake documentation says about CMAKE_PREFIX_PATH:
Semicolon-separated list of directories specifying installation
prefixes to be searched by the find_package(), find_program(), find_library(),
find_file(), and find_path() commands.
and we're setting CMAKE_PREFIX_PATH, so if any of the include or library checks
use CMAKE_PREFIX_PATH, then they might find headers for the libpcap installed
in /tmp/libpcap, even though the build itself will use flags from the system
libpcap.pc.
The CMake 3.19 documentation for FindPkgConfig, which is the module for using
pkg-config:
https://cmake.org/cmake/help/v3.19/module/FindPkgConfig.html
says:
PKG_CONFIG_USE_CMAKE_PREFIX_PATH
Specifies whether pkg_check_modules() and pkg_search_module()
should add the paths in the CMAKE_PREFIX_PATH, CMAKE_FRAMEWORK_PATH and
CMAKE_APPBUNDLE_PATH cache and environment variables to thepkg-config search
path.
If this variable is not set, this behavior is enabled by
default if CMAKE_MINIMUM_REQUIRED_VERSION is 3.1 or later, disabled otherwise.
So we should either 1) require CMake 3.1 or later or 2) forcibly set
PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do the
latter.
Once all the other stuff I've checked in passes Travis, I'll try that instead
of explicitly setting PKG_CONFIG_PATH. and see if that works.
> 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
Try that with
PKG_CONFIG_PATH=/tmp/libpcap/lib/pkgconfig cmake -DWITH_CRYPTO="yes"
-DCMAKE_PREFIX_PATH=/tmp/libpcap -DC
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers wrote: > So we should either 1) require CMake 3.1 or later or 2) forcibly set > PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do > the latter. That won't work - PKG_CONFIG_USE_CMAKE_PREFIX_PATH *isn't supported* prior to 3.1. 3.1 dates back to 2015. That might be sufficient to treat as a minimum.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] libpcap detection and linking in tcpdump
--- Begin Message --- On Thu, 7 Jan 2021 16:46:41 -0800 Guy Harris wrote: > 3.1 dates back to 2015. That might be sufficient to treat as a > minimum. 5 years of backward compatibility might be OK'ish, although from time to time I run into such "long-term support" systems that in practice mean someone keeps paying good money for "support" for 5-10 years, but they don't get bugs fixed or new software versions backported. In my own experience this tends to have something to do with RedHat Linux distributions. Regarding the solution you consider, I have not tried the fixes from your previous message yet and I do not understand every facet of the problem. Have you considered to declare somewhere that certain ways of building work only in this and this particular basic manner? And/or to disable some smart ways of libpcap detection automatically if cmake is too old, instead of failing the build outright? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
