On Tue, Apr 02, 2024 at 06:34:43PM -0400, Jeffrey Walton wrote: > On Tue, Apr 2, 2024 at 6:24 PM Chung Jonathan <jch...@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.
