1

I'm using an application, PowerISO, that comes with no source code, only its binary and the required shared libraries.

I've used it for a number of years on Debian 10, but now I'm on Debian 12, it no longer works. The program comes with its own bash wrapper script, which is run when in the binary directory. It sets the LD_LIBRARY_PATH and QT_QPA_PLATFORM_PLUGIN_PATH environment variables to the directory where the binary and shared libraries are located before executing the binary. It then unsets the LD_LIBRARY_PATH environment variable upon exiting the program.

/home/jimjamz/opt/poweriso-x64/poweriso.sh:

export LD_LIBRARY_PATH=.
export QT_QPA_PLATFORM_PLUGIN_PATH=.
./poweriso
unset LD_LIBRARY_PATH

When executed from within the same directory. the following error is displayed when running the poweriso.sh wrapper script:

qt.qpa.plugin: Could not find the Qt platform plugin "xcb" in "."
This application failed to start because no Qt platform plugin could be initialized. Reinstalling the application may fix this problem.

Available platform plugins are: xcb (from .).

./poweriso.sh: line 3: 27182 Aborted                 ./poweriso

ldd on libxcb.so.1 located in the binary directory reports shared libraries being used are in /lib/x86_64-linux-gnu/ and not in the same binary directory, where there is a separate copy specifically for the application:

$ ldd /home/jimjamz/opt/poweriso-x64/libxcb.so.1
linux-vdso.so.1 (0x00007ffe745ef000)
    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007fe1bf7bf000)
    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007fe1bf400000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe1bf21f000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007fe1bf7a9000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fe1bf808000)
    libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007fe1bf79c000)

ldd on the binary also shows shared libraries as ones from other directories, as well as the binary's own directory:

$ ldd /home/jimjamz/opt/poweriso-x64/poweriso
./poweriso: ./libc.so.6: version `GLIBC_2.34' not found (required by libGLX.so.0)
./poweriso: ./libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libGLdispatch.so.0)
./poweriso: ./libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
./poweriso: ./libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
./poweriso: ./libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libbsd.so.0)
./poweriso: ./libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libmd.so.0)
    linux-vdso.so.1 (0x00007ffc676ea000)
    libQt5Gui.so.5 => ./libQt5Gui.so.5 (0x00007f0550400000)
    libQt5Core.so.5 => ./libQt5Core.so.5 (0x00007f054fc00000)
    libQt5Widgets.so.5 => ./libQt5Widgets.so.5 (0x00007f054f200000)
    libpthread.so.0 => ./libpthread.so.0 (0x00007f05511f6000)
    libstdc++.so.6 => ./libstdc++.so.6 (0x00007f0550c76000)
    libgcc_s.so.1 => ./libgcc_s.so.1 (0x00007f05511da000)
    libc.so.6 => ./libc.so.6 (0x00007f054f016000)
    libGL.so.1 => /home/jimjamz/opt/poweriso-x64/./libGL.so.1 (0x00007f0551146000)
    libz.so.1 => /home/jimjamz/opt/poweriso-x64/./libz.so.1 (0x00007f054ec00000)
    libm.so.6 => /home/jimjamz/opt/poweriso-x64/./libm.so.6 (0x00007f054fa73000)
    libicui18n.so.56 => /home/jimjamz/opt/poweriso-x64/./libicui18n.so.56 (0x00007f054e600000)
    libicuuc.so.56 => /home/jimjamz/opt/poweriso-x64/./libicuuc.so.56 (0x00007f054e200000)
    libicudata.so.56 => /home/jimjamz/opt/poweriso-x64/./libicudata.so.56 (0x00007f054c800000)
    libdl.so.2 => /home/jimjamz/opt/poweriso-x64/./libdl.so.2 (0x00007f055113e000)
    libgthread-2.0.so.0 => /home/jimjamz/opt/poweriso-x64/./libgthread-2.0.so.0 (0x00007f0551139000)
    libglib-2.0.so.0 => /home/jimjamz/opt/poweriso-x64/./libglib-2.0.so.0 (0x00007f054eef9000)
    ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f0551219000)
    libGLX.so.0 => /lib/x86_64-linux-gnu/libGLX.so.0 (0x00007f05510ea000)
    libGLdispatch.so.0 => /lib/x86_64-linux-gnu/libGLdispatch.so.0 (0x00007f054ee40000)
    libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007f054eb88000)
    libX11.so.6 => /lib/x86_64-linux-gnu/libX11.so.6 (0x00007f054c6be000)
    libxcb.so.1 => /lib/x86_64-linux-gnu/libxcb.so.1 (0x00007f05510be000)
    libXau.so.6 => /lib/x86_64-linux-gnu/libXau.so.6 (0x00007f05510b9000)
    libXdmcp.so.6 => /lib/x86_64-linux-gnu/libXdmcp.so.6 (0x00007f054c400000)
    libbsd.so.0 => /lib/x86_64-linux-gnu/libbsd.so.0 (0x00007f0550c60000)
    libmd.so.0 => /lib/x86_64-linux-gnu/libmd.so.0 (0x00007f05510ac000)

I don't want the binary to use any shared libraries other than those that are already provided in the binary's own directory (/home/jimjamz/opt/poweriso-x64), as GLIBC 2.33 and 2.34 no longer exist in my current Debian distribution's libc6. From what I've read, only the current and previous version are catered for in libc. In my case, that would be 2.36 and 2.35:

libc6 is already the newest version (2.36-9+deb12u4).
ldd (Debian GLIBC 2.36-9+deb12u4) 2.36

ldd on libc.so.6 in the binary directory, shows that another directory, /lib64, is also being used:

$ ldd /home/jimjamz/opt/poweriso-x64/libc.so.6

/lib64/ld-linux-x86-64.so.2 (0x00007f4cb1d1d000)
    linux-vdso.so.1 (0x00007fff1a7f4000)

I created a bash wrapper script of my own to set the LD_LIBRARY_PATH and QT_QPA_PLATFORM_PLUGIN_PATH environment variables to the binary's directory, but it resulted in the original error message. Attempting to include the binary directory in either /etc/ld.so.conf.d/poweriso.conf or directly in /etc/ld.so.conf was a bad idea, resulting in a kernel panic.

I read about similar issues and related solutions, using patchelf to set the rpath.

patchelf --set-rpath /home/jimjamz/opt/poweriso-x64 poweriso

and confirmed it was set to the correct directory:

$ patchelf --print-rpath poweriso
/home/jimjamz/opt/poweriso-x64

But, when I execute the binary directly I receive:

./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libGLX.so.0)
./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libGLdispatch.so.0)
./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.34' not found (required by /lib/x86_64-linux-gnu/libX11.so.6)
./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libbsd.so.0)
./poweriso: /home/jimjamz/opt/poweriso-x64/libc.so.6: version `GLIBC_2.33' not found (required by /lib/x86_64-linux-gnu/libmd.so.0)

Despite using patchelf to set the rpath, the binary still attempts to link to shared libraries in /lib/x86_64-linux-gnu/.

Running patchelf with --debug reports that nothing was changed, and I confirmed this with a SHA-1 comparison of the binary pre- and post-patch:

patching ELF file 'poweriso'
not modified, but alwaysWrite=true
writing poweriso.log

I suspect that the whole issue is because the binary is trying to use system libraries instead of the provided ones, as mentioned here.

Q: How can I force the binary to use its own directory for the shared libraries it requires? This was the author's intention, hence the provision of said libraries.

References:

How do you specify the location of libraries to a binary? (linux)

https://stackoverflow.com/questions/68036484

Improve this question
2
  • Try LD_LIBRARY_PATH=/your/full/path:$LD_LIBRARY_PATH.
    – harrymc
    Commented Feb 18 at 20:10
  • @harrymc - I should have mentioned it in my own wrapper script, that I attempted what you suggested as a colon-separated variable, with the full path to the binary and shared libraries location followed by the existing variable value. I got the same qt.qpa.plugin error as before. I also tried the full path, followed by /lib/x86_64-linux-gnu as the last value to see if that would force the priority of directories used, but without success.
    – jimjamz
    Commented Feb 22 at 17:51

1 Answer 1

Reset to default
2

In essence, you want to make PowerISO into a SNAP package, not a bad idea, though I do not know how to do so.

However, PowerISO is available in versions for Windows operating system. According to the wine compatibility database, versions 4.0 through 7.9 of PowerISO have been tested, and functionality rated "Platinum". Since wine creates a self-contained "Windows system" for each application, that should meet your needs, i.e., letting PowerISO see only the relevant libraries.

Try using the current version of PowerISO, v.8.7, and if that does not work, try the last tested in wine, v.7.9. If there are issues, update to the latest version of wine.

BTW, on Ubuntu, a Debian-based distro, I find 7-Zip runs very well under wine, and provides some of the functionality of PowerISO. Unlike PowerISO, which appears to have stopped development in 2019, 7-Zip is being kept up-to-date.

Improve this answer
2
  • Although I do appreciate the solution of using WINE to run the Windows equivalent of the application, I was already aware of this. Instead, my objective (and my original question) pertains to forcing the shared libraries to point to a specific directory, so that the native linux version of the (or another similar) application can continue to be used.
    – jimjamz
    Commented Feb 22 at 17:55
  • @jimjamz, agreed -- if you can find a SNAP version of the app, all libraries are included in its environment. Otherwise, wine does the same, albeit not for a native version.
    – DrMoishe Pippik
    Commented Feb 22 at 22:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .