[SOLVED] compiling a static 32 bit binary which will run on a 64 bit os.

rkelsen · 05-28-2013, 07:08 PM

Can this be done?

I'm trying to compile a static binary on a 32 bit machine which can run anywhere.

My build environment is Slackware 13.37 with rebuilt versions of certain library packages (SDL being the main one) which include the ".a" static library files. In order to do this, I've used the stock Slackbuilds from the Slackware source tree, with the only change being the removal of "--disable-static" from the SlackBuild file, [and/or insertion of "--enable-static" if necessary].

After compiling my static binary, the result I get is a file which runs fine on a 32 bit machine and a 64 bit 'multilib' setup. But attempting to run it on a pure 64 bit OS yields output containing words to the effect of "file not found".

ldd tells me that my binary is not dynamically linked (which is what I want).

I'm trying to avoid the need to provide a separate 64 bit package in addition to the 32 bit one. Is it possible?

Petri Kaukasoina · 05-29-2013, 12:08 AM

Quote:

Originally Posted by rkelsen

I'm trying to compile a static binary on a 32 bit machine which can run anywhere.

After compiling my static binary, the result I get is a file which runs fine on a 32 bit machine and a 64 bit 'multilib' setup. But attempting to run it on a pure 64 bit OS yields output containing words to the effect of "file not found".

A simple test program linking only to libc worked ok here. Compiled on 32-bit Slackware, with -static, runs fine on a pure 64-bit Slackware. (Slackware 64-bit kernel uses CONFIG_IA32_EMULATION=y, without that it would not work.)

What does 'strace a.out' say (if your binary is called a.out) ? Maybe you can see which file is not found.

rkelsen · 05-29-2013, 06:56 AM

Hi, thanks for your response.

This is the output I get:

Code:

bash-4.2$ strace ./scummvm-static 
execve("./scummvm-static", ["./scummvm-static"], [/* 55 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8002 (flags O_RDWR|O_LARGEFILE)
fstat(3, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 1), ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f8ef4584000
lseek(3, 0, SEEK_CUR)                   = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3)                                = 0
munmap(0x7f8ef4584000, 4096)            = 0
exit_group(1)                           = ?
bash-4.2$

Any clues there?

turtleli · 05-29-2013, 08:02 AM

Could you check the output of

Code:

readelf -d your_program

to see whether it links to any shared libraries? ldd may claim that your binary is not a dynamic executable if it can't read it properly.

Petri Kaukasoina · 05-29-2013, 12:49 PM

This is also good to check:

Code:

readelf --program-headers ./scummvm-static

If I compile a test program without '-static' the output contains

Code:

  INTERP         0x000134 0x08048134 0x08048134 0x00013 0x00013 R   0x1
      [Requesting program interpreter: /lib/ld-linux.so.2]

and it won't run on the 64-bit system because the 32-bit dynamic loader is missing. And strace will print out exactly similar output to what you get. But if I use '-static', the output does not request the dynamic loader and the program runs on the 64-bit system.

rkelsen · 05-30-2013, 10:05 AM

Quote:

Originally Posted by Petri Kaukasoina

And strace will print out exactly similar output to what you get.

Well this is embarrassing...

It turns out that I wasn't actually using the -static option. So, you are right!

But now I have a different problem.

Toward the end of the compile, I get an error which says:

Code:

/usr/lib/libSDL.a(SDL_sysloadso.o): In function `SDL_LoadObject':
SDL_sysloadso.c:(.text+0x1b): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld: cannot find -lX11
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld: cannot find -lXext
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld: cannot find -lXrandr
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld: cannot find -lXrender
/usr/lib/gcc/i486-slackware-linux/4.7.1/../../../../i486-slackware-linux/bin/ld: cannot find -lvga
backends/libbackends.a(timidity.o): In function `MidiDriver_TIMIDITY::host_to_addr(char const*):
/home/rob/packages/scummvm/scummvm-1.6.0/backends/midi/timidity.cpp:288: warning: Using 'getbyhostname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking
collect2: error: ld returned 1 exit status
make: *** [scummvm-static] Error 1
rob@here:~/packages/scummvm/scummvm-1.6.0$

Do I need to add something to the Makefile?

rg3 · 05-30-2013, 01:29 PM

Some libraries in Slackware are shipped without their static counterparts. This means you can't generate a static binary if the program depends on them. My impression is those libraries listed in the error message are in that situation.

Petri Kaukasoina · 05-31-2013, 12:44 AM

Quote:

backends/libbackends.a(timidity.o): In function `MidiDriver_TIMIDITY::host_to_addr(char const*):
timidity.cpp:288: warning: Using 'getbyhostname' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

Depending of what /etc/nsswitch.conf contains, libc uses different methods to resolve host names to ip addresses. So even the static libc has to load dynamically one of the /lib/libnss_*.so, for example /lib/libnss_files.so.2 and /lib/libnss_dns.so.2 if you have 'hosts: files dns' in nsswitch.conf.

Quote:

/usr/lib/libSDL.a(SDL_sysloadso.o): In function `SDL_LoadObject':
SDL_sysloadso.c

.text+0x1b): warning: Using 'dlopen' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking

This wants to use dlopen. It's the interface to the dynamic loader to open a shared library.

So, you found two places which need the dynamic loader. You might be able to get rid of it if you can remove some code but you would probably lose some functionality as well.

rkelsen · 05-31-2013, 04:54 AM

This whole exercise has been great learning experience for me.

Looks like I'll just have to provide 2 binaries.

Thanks to all who helped.