On Tue, Apr 02, 2024 at 06:34:43PM -0400, Jeffrey Walton wrote:
On Tue, Apr 2, 2024 at 6:24 PM Chung Jonathan <jchung@student.ethz.ch> wrote:
Dear Franco Martelli, dear Thomas Schmitt,
Sorry for the potential duplication. This mail should now also go to the list.
I believe I found the problem which was on my side. I do have libz.so.1.3, since I manually compiled grpc on my machine and this also uses a newer version of zlib appearently. So this is not a Debian problem but rather specific to my setup. A clean
install in a VM indeed works as expected.
Do you still think a bug report is worth it?
Your problem is one that plagues Linux. You compile and link against
one version of a library, and then you runtime link against another
version. This should have been fixed for users a long time ago, but
the folks responsible leave users to suffer it. I consider it a
security bug since essentially random libraries are being loaded at
runtime.
To fix the problem yourself, add an RPATH to your LDFLAGS when
building your program:
-Wl,-rpath=/path/to/expected/libz -Wl,--enable-new-dtags
The loader will encounter the RPATH when loading your executable, and
load the correct library for your program.
I've run into a variant of this issue myself. I had compiled an
upstream version of Tcl, which builds a shared library named libtcl8.6.so
in the lib/ subdirectory of the --prefix used for ./configure, where
the default value of --prefix is /usr/local.
This places the shared library in /usr/local/lib which happens to be in
the default set of paths used by ldconfig and ld.so. Which in turn
means that the locally built library gets used when running Debian's
packaged version of Tcl, taking priority over the version installed in /usr/lib/x86_64-linux-gnu/ or whatver arch-specific directory is used.
In my case, the solution was to build my local version of Tcl with a
different --prefix. Then there's nothing dropped into /usr/local/lib
and there's no conflict with the system's packages.
Of course, this is a particularly subtle problem that most users are not
going to be aware of. It's specific to packages that build part of
themselves as a shared library, which immediately makes most programs
immune to it. But when it *does* affect you, it can be tricky to
figure out what's happening.
It sounds like the OP's pigz issue was of a similar nature. If this is
the case, then filing a Debian bug report isn't going to be helpful,
unless it's done as a sort of documentation for anyone else who runs
into the same problem in the future.
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)