Your message dated Sat, 23 Nov 2024 19:45:01 +0100
with message-id <E1tEv7t-0000000D27B-0Hnt@sandy>
and subject line Re: Bug#1088017: cmake 3.31 regression: injects -Wl in middle
of linker flags
has caused the Debian Bug report #1088017,
regarding cmake 3.31 regression: injects -Wl in middle of linker flags
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
1088017: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1088017
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: cmake
Version: 3.31.0-2
Severity: serious
Justification: FTBFS
Control: block 1087764 by -1
cmake 3.31 has made a radical overhaul of LINKER handling, and appears
to have introduced a regression handling -Wl in LDFLAGS.
We applied a linker-related upstream patch in Bug#1087983, but the
problem persists, see the FTBFS in paraview,
https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=arm64&ver=5.13.1%2Bdfsg-8&stamp=1732229551&raw=0
The debian build system (dpkg-buildflags) sets
LDFLAGS=-Wl,-z,relro
cmake seems to acknowledge LDFLAGS appropriately, for instance
CMakeCache.txt contains entries like
CMAKE_SHARED_LINKER_FLAGS:STRING=-Wl,-z,relro
But the linker.txt generated for specific targets gives linker flags
as, for instance
/usr/bin/cc -fPIC -g -O2 -Werror=implicit-function-declaration
-ffile-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong
-fstack-clash-protection -Wformat -Werror=format-security
-mbranch-protection=standard -Wdate-time -D_FORTIFY_SOURCE=2 -Wall -pedantic
-g -Wl,-lc,-Wl,-z,relro,-Wl,--as-needed
-Wl,--dependency-file,CMakeFiles/WrappingTools.dir/link.d -Wl,-z,relro
-Wl,--as-needed ...
(linking libvtkWrappingTools-pv5.13.so.5.13 in
https://buildd.debian.org/status/fetch.php?pkg=paraview&arch=arm64&ver=5.13.1%2Bdfsg-8&stamp=1732229551&raw=0
)
Later in the options we see "-Wl,-z,relro -Wl,--as-needed -shared",
which would be fine. But before that, linker.txt has been generated with
-Wl,-lc,-Wl,-z,relro,-Wl,--as-needed
Here the linker flags have been amalgamated into one -Wl linker string,
but the -Wl before each separate flag (used in LDFLAGS) has not been
stripped out. Then -Wl appears in the middle of the linker flags, so
is treated as a linker flag itself rather than a compiler flag to send
to the linker. Hence a build error results,
[ 0%] Linking C shared library
../../../lib/aarch64-linux-gnu/libvtkWrappingTools-pv5.13.so
cd /<<PKGBUILDDIR>>/build.python3.13/VTK/Wrapping/Tools && /usr/bin/cmake -E
cmake_link_script CMakeFiles/WrappingTools.dir/link.txt --verbose=1
/usr/bin/ld: unrecognized option '-Wl'
/usr/bin/ld: use the --help option for usage information
collect2: error: ld returned 1 exit status
It looks the new cmake 3.31 LINKER system would be supposed to strip out the
intermediate -Wl substrings, but is not doing so. It also looks wrong
that the linker flags are set concatenated like this, but then
repeated separately further down the command line.
The failing concatenated option has prepended -Wl,-lc which is not in
dpkg-buildflags and not in paraview's debian/rules. This might be a
clue where the problem is happening.
-- System Information:
Debian Release: trixie/sid
APT prefers unstable-debug
APT policy: (500, 'unstable-debug'), (500, 'unstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 6.11.9-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_WARN, TAINT_OOT_MODULE
Locale: LANG=en_AU.UTF-8, LC_CTYPE=en_AU.UTF-8 (charmap=UTF-8),
LANGUAGE=en_AU:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages cmake depends on:
ii cmake-data 3.31.0-2
ii libarchive13t64 3.7.4-1.1
ii libc6 2.40-3
ii libcurl4t64 8.11.0-1
ii libexpat1 2.6.4-1
ii libgcc-s1 14.2.0-8
ii libjsoncpp26 1.9.6-3
ii librhash1 1.4.5-1
ii libstdc++6 14.2.0-8
ii libuv1t64 1.48.0-7
ii procps 2:4.0.4-6
ii zlib1g 1:1.3.dfsg+really1.3.1-1+b1
Versions of packages cmake recommends:
ii gcc 4:14.2.0-1
ii make 4.3-4.1
Versions of packages cmake suggests:
pn cmake-doc <none>
pn cmake-format <none>
pn elpa-cmake-mode <none>
ii ninja-build 1.12.1-1
-- no debconf information
--- End Message ---
--- Begin Message ---
Brad King dug in and identified that the paraview problem was indeed a paraview
problem
in the cmake files used by paraview.
The changes in cmake 3.31 simply exposed the problem, which was already there
in paraview.
Brad has open up the issue upstream for further discussion. Perhaps cmake can
handle these
-Wl flags more robustly.
We'll receive any further patches they make to cmake in due course,
but in the short time the acute problem has been identified and fixed
in paraview 5.13.1+dfsg-9.
The issue is no longer severity serious as far as cmake goes,
and in fact there's nothing more for debian to do at this point
except keep up with upstream cmake releases.
That is, the packaging issue is resolved,
so I'll close this bug now.
Drew
--- End Message ---
