Module -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 Shared -Wl,-O1 -Wl,--as-needed -Wl,--defsym=__gentoo_check_ldflags__=0 -- Configuring done CMake Error at boreas/CMakeLists.txt:87 (add_executable): Target "alivedetection-test" links to item " -lpcap" which has leading or trailing whitespace. This is now an error according to policy CMP0004. ------------------------------------------------------------------- This is an unstable amd64 chroot image at a tinderbox (==build bot) name: 17.0_musl_hardened-j4-20211213-184654 ------------------------------------------------------------------- gcc-config -l: [1] x86_64-gentoo-linux-musl-11.2.1 * clang version 13.0.0 Target: x86_64-gentoo-linux-musl Thread model: posix InstalledDir: /usr/lib/llvm/13/bin /usr/lib/llvm/13 13.0.0 Python 3.9.9 Available Ruby profiles: [1] ruby26 (with Rubygems) [2] ruby27 (with Rubygems) [3] ruby30 (with Rubygems) * Available Rust versions: [1] rust-1.57.0 * php cli: HEAD of ::gentoo commit e0d122589ba62c02c234e60784917d88955ad516 Author: Repository mirror & CI <repomirrorci@gentoo.org> Date: Tue Dec 14 13:51:50 2021 +0000 2021-12-14 13:51:47 UTC emerge -qpvO net-analyzer/gvm-libs [ebuild N ] net-analyzer/gvm-libs-20.8.1 USE="-extras -ldap -radius -test"
Created attachment 758973 [details] emerge-info.txt
Created attachment 758974 [details] emerge-history.txt
Created attachment 758975 [details] environment
Created attachment 758976 [details] etc.portage.tar.bz2
Created attachment 758977 [details] logs.tar.bz2
Created attachment 758978 [details] net-analyzer:gvm-libs-20.8.1:20211214-150918.log
Created attachment 758979 [details] temp.tar.bz2
I'm getting this bug as of today. It stems from a "bug" in pcap-config and the pkg-config of libpcap (1.10.3, possibly others). I have an idea of the problem, but not a clear solution. Recent CMake does not accept " -lpcap" as input for the linker, because it has a leading space. This additional space is present in both the pkg-config file and pcap-config of libpcap in several places. 1) Several ocurrences of " -lpcap" instead of " -lpcap" (two instead of one separating space) 2) in pcap-config in the last else clause, the output contains an empty $LIBS which causes a leading space in the output too. Fixing 1 and 2 manually on my system fixed the bug we are experiencing here. I suggest that libcap needs to be changed in order to solve this bug. I can imagine more packages having similar bugs which will get uncovered by the new, stricter behaviour of cmake. I'd literally midnight and I do not have a clear idea how exactly to go on. Maybe someone can pick up here?
Upstream patch: https://github.com/greenbone/gvm-libs/commit/de63a18fd2263b89bed70c00f7232939b0744002.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b7ad8ff888194db07b1d8fdba6c91ef9b2337176 commit b7ad8ff888194db07b1d8fdba6c91ef9b2337176 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-04-03 05:30:02 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-04-03 05:30:02 +0000 net-analyzer/gvm-libs: fix build w/ misbehaving pcap-config Closes: https://bugs.gentoo.org/829183 Signed-off-by: Sam James <sam@gentoo.org> .../gvm-libs-21.4.4-pcap-config-whitespace.patch | 34 ++++++++++++++++++++++ net-analyzer/gvm-libs/gvm-libs-21.4.4-r3.ebuild | 3 +- 2 files changed, 36 insertions(+), 1 deletion(-)
(In reply to satmd from comment #8) > I'm getting this bug as of today. > > It stems from a "bug" in pcap-config and the pkg-config of libpcap (1.10.3, > possibly others). > > I have an idea of the problem, but not a clear solution. > > Recent CMake does not accept " -lpcap" as input for the linker, because it > has a leading space. > > This additional space is present in both the pkg-config file and pcap-config > of libpcap in several places. > > 1) Several ocurrences of " -lpcap" instead of " -lpcap" (two instead of one > separating space) > 2) in pcap-config in the last else clause, the output contains an empty > $LIBS which causes a leading space in the output too. > > Fixing 1 and 2 manually on my system fixed the bug we are experiencing here. > > I suggest that libcap needs to be changed in order to solve this bug. I can > imagine more packages having similar bugs which will get uncovered by the > new, stricter behaviour of cmake. > > I'd literally midnight and I do not have a clear idea how exactly to go on. > Maybe someone can pick up here? Yeah, it's definitely a problem in pcap itself. A bug really needs to be filed upstream for that - and, I mean, even better would be us just disabling it entirely, but unfortunately a lot of packages would break.
The output of ancient legacy foo-config scripts that shouldn't be used, is a shell-formatted command string that must be splitted into shell words and then used. The failure mode here is that it "works with one space but breaks with two spaces" which tells me this is a CMakeLists.txt bug for not parsing the output as a shell does :p it is not a pcap-config bug and it would be incorrect to report one to libpcap. (Also as usual meson gets this right so projects don't have to. Using the pkg-config file for libpcap if it exists. That's the real solution by the way, because upstream specifically keeps that shell script around for the sake of people that don't have pkg-config installed.)
