1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Running 32-bit static exeutable on 64-bit Debian

    From Van Snyder@21:1/5 to All on Sat Jul 20 07:00:01 2024
    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).


    <html><head></head><body><div>I'm trying to run a 32-bit static executable on 64-bit Debian 12.5 "bookworm."</div><div><br></div><div>When I launch it, I get</div><div><br></div><div>./LinuxSusser: error while loading shared libraries: libgtk-x11-2.0.so.
    0: cannot open shared object file: No such file or directory</div><div><br></div><div>Why is a static executable wanting to load a .so file?</div><div><br></div><div>i386 is in my arch list in /etc/apt/sources.list. I've done "apt update"</div><div><br></
    <div>The 64-bit version of the file exists.</div><div><br></div><div>I used to be able to run this program in Debian 10.</div><div><br></div><div>How do I run it now? The author has retired and isn't interested in building a 64-bit executable (static
    or otherwise).</div><div><br></div><div><span></span></div></body></html>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Schmitt@21:1/5 to Van Snyder on Sat Jul 20 09:30:02 2024
    Hi,

    Van Snyder wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Schmitt@21:1/5 to Van Snyder on Sat Jul 20 10:50:01 2024
    Hi,

    Van Snyder wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Greg Wooledge@21:1/5 to Van Snyder on Sat Jul 20 16:00:01 2024
    On Sat, Jul 20, 2024 at 01:15:22 -0700, Van Snyder wrote:
    Van Snyder wrote:
    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.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Thomas Schmitt@21:1/5 to Greg Wooledge on Sat Jul 20 17:20:01 2024
    Hi,

    Greg Wooledge wrote:
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)