Running 32-bit static exeutable on 64-bit Debian

[Van Snyder]

I'm trying to run a 32-bit static executable on 64-bit Debian 12.5
"bookworm."

When I launch it, I get

./LinuxSusser: error while loading shared libraries: libgtk-x11-
2.0.so.0: cannot open shared object file: No such file or directory

Why is a static executable wanting to load a .so file?

i386 is in my arch list in /etc/apt/sources.list. I've done "apt
update"

The 64-bit version of the file exists.

I used to be able to run this program in Debian 10.

How do I run it now? The author has retired and isn't interested in
building a 64-bit executable (static or otherwise).

[David]

I'm trying to run a 32-bit static executable on 64-bit Debian 12.5 "bookworm."
When I launch it, I get
./LinuxSusser: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Hi, try
apt list --installed '*libgtk2.0*'
which you will want to show that the i386 version of the libgtk2.0-0
package is installed alongside any other versions present.

If it does not appear there then try installing it, using whatever package
manager you prefer, and specify that you want the i386 package to be
co-installed with any other versions already present.

Reference:
https://packages.debian.org/search?searchon=contents&keywords=libgtk-x11&mode=filename&suite=stable&arch=any

[David]

Post by David

I'm trying to run a 32-bit static executable on 64-bit Debian 12.5 "bookworm."
When I launch it, I get
./LinuxSusser: error while loading shared libraries: libgtk-x11-2.0.so.0: cannot open shared object file: No such file or directory

Hi, try
apt list --installed '*libgtk2.0*'
which you will want to show that the i386 version of the libgtk2.0-0
package is installed alongside any other versions present.
If it does not appear there then try installing it, using whatever package
manager you prefer, and specify that you want the i386 package to be
co-installed with any other versions already present.

I suspected it's not installed, so I had already done
# find /usr/lib -name '*libgtk2.0*'
/usr/lib/x86_64-linux-gnu/libgtk2.0-0
(I also used "locate" and didn't find it.)

Hi, unfortunately I am unable to understand from this reply whether you
ran the command I suggested, or not.

'apt' or its friends are the useful toolkit to help solve problems like this,
not 'find'. The main point of a distribution like Debian is that it provides
_packaged_ software.

I made sure that i386 is in the arch list in /etc/apt/sources.list. Then
I ran "apt update" but it didn't install the i386 version.

'apt update' never installs anything. You have to use for example
'apt install' to specify that you want a package installed.

Does it exist?

In my previous message I already provided a link to a page showing
that an i386 version of the missing library it exists in Debian.
It won't be found on your machine until you install it though.

How do I force it to install?

Regarding how to install it, use the instructions here:
https://wiki.debian.org/Multiarch/HOWTO

[Thomas Schmitt]

Hi,

And there's still the mystery why a statically-linked executable wants to
load a shared object library.

I doubt that it is possible to make a purely statical binary with no
references to .any so libraries.
(If it were generally possible, why then exist Flatpack and Snap ?)

Check by program "ldd" which dynamic dependencies the binary has:

ldd ./LinuxSusser


Have a nice day :)

Thomas

[Jeffrey Walton]

Post by Thomas Schmitt

And there's still the mystery why a statically-linked executable wants to
load a shared object library.

I doubt that it is possible to make a purely statical binary with no
references to .any so libraries.
(If it were generally possible, why then exist Flatpack and Snap ?)
ldd ./LinuxSusser

You might want to use `libtree <module>, `readelf -d <module> | grep
NEEDED` or `objdump -p <module> | grep NEEDED` instead. They do not
suffer ldd shortcomings. Also see CVE-2009-5064, and
<https://jmmv.dev/2023/07/ldd-untrusted-binaries.html>.

Jeff

[Greg Wooledge]

And there's still the mystery why a statically-linked executable wants to
load a shared object library.

https://manpages.debian.org/bookworm/manpages-dev/dlopen.3.en.html

Am I losing my mind?
At first I had done "file LinuxSusser". It reported "Statically
linked."
Just to be sure, I did the recommended "ldd LinuxSusser." It also
reported Statically linked."

Then it's almost certainly using dlopen() to load this shared library.

The unpleasant part is that once you install this 32-bit shared lib,
you'll get past this one dlopen() call, and then there might be more
of them. You'll just have to whittle it down piece by piece until
it stops crashing. There's no way to get a complete list all at once.

Your testing will also have to try to cover as many code paths as
possible. Maybe there's a shared lib that only gets read when you
activate a specific feature in the program. You'll have to try to
test as many features as you can, before you can be reasonably sure
you've got all the libs it will want.

[Thomas Schmitt]

Hi,

Post by Greg Wooledge
Then it's almost certainly using dlopen() to load this shared library.

dlopen(3) explains the missing gtk modules which (i assume) are not
reported by ldd. But it does not explain why "file" and ldd now report
something different than they reported a while ago.


Have a nice day :)

Thomas

[Nicholas Geovanis]

Post by Greg Wooledge

And there's still the mystery why a statically-linked executable wants to
load a shared object library.

https://manpages.debian.org/bookworm/manpages-dev/dlopen.3.en.html

Am I losing my mind?
At first I had done "file LinuxSusser". It reported "Statically
linked."
Just to be sure, I did the recommended "ldd LinuxSusser." It also
reported Statically linked."

Then it's almost certainly using dlopen() to load this shared library.

If LD_LIBRARY_PATH is set to null or "" in that executable's environment
and you then invoke it, what happens?

[Thomas Schmitt]

Hi,

Am I losing my mind?

Since this could mean a fatal end to the endeavor to run your program
we should postpone this hypothesis until nearly everything else is
outruled.

At first I had done "file LinuxSusser". It reported "Statically linked."
Just to be sure, I did the recommended "ldd LinuxSusser." It also reported
Statically linked."
When I retry them, "file" says it's dynamically linked, and "ldd" reports
about two dozen links to missing shared object libraries.
[...]
so I don't understand why it was statically linked a few
hours ago. The file's time stamp hasn't changed.

Can it be that you have more than one file named "LinuxSusser" ?

Now, instead of simply refusing to run, or (the original "Command not
found") it lists a bunch of missing gtk modules (atk-bridge, pixmap,
adwaita), not missing shared object libraries. Where do I get the missing
gtk modules?

If you are lucky, then this might give an answer:

apt-file search atk-bridge


Have a nice day :)

Thomas