Difference between revisions of "64bit Linux issues"

From Noah.org
Jump to navigationJump to search
 
m
 
(One intermediate revision by the same user not shown)
Line 2: Line 2:
  
 
Almost all source packages use the "./configure && make && make install" idiom.
 
Almost all source packages use the "./configure && make && make install" idiom.
This is well and fine, but most of the "configure" scripts were generate with
+
This is well and fine, but most of the "configure" scripts were generated with
autoconf on 32-bit machines. You may see this error when you try to build a package from source
+
`autoconf` on 32-bit machines. You may see this error when you try to build a package from source
 
on 64-bit Linux:
 
on 64-bit Linux:
 
   /usr/lib/libpopt.so: could not read symbols: File in wrong format
 
   /usr/lib/libpopt.so: could not read symbols: File in wrong format
Line 11: Line 11:
 
Then try the ancient incantation again:
 
Then try the ancient incantation again:
 
   ./configure && make && make install
 
   ./configure && make && make install
 +
 +
== 32-bit binaries won't run on 64-bit machines ==
 +
 +
This is an annoying problem because the error messages are very misleading. When I was trying to use a crosscompiler toolchain built for 32-bit Linux under a 64-bit kernel I would get this following error:
 +
<pre>
 +
$ mips-linux-uclibc-gcc
 +
-bash: mips-linux-uclibc-gcc: No such file or directory
 +
</pre>
 +
I could see that the executable was in my path and the execute permissions were set. Even if I gave the full path to the executable I would get an error saying "No such file or directory". I ran the binary under `strace` and it fail at the very first instruction '''execve("./mips-linux-uclibc-gcc", ["./mips-linux-uclibc-gcc"], [/* 41 vars */]) = -1 ENOENT (No such file or directory)'''. I knew that '''mips-linux-uclibc-gcc''' wasn't breaking down on some missing or broken library dependency because toolchains by their nature tend to be built with their libraries statically linked. This way a toolchain can be reused on other machines without worrying about dependencies, and you don't have to wonder if different versions of libraries might result in different code being emitte. A quick check with `ldd` showed no external library dependencies.
 +
<pre>
 +
$ ldd mips-linux-uclibc-gcc
 +
        not a dynamic executable
 +
</pre>
 +
Eventually I figured out that my system was entirely missing 32bit support. Installing it under Ubuntu was as simple as running:
 +
<pre>
 +
aptitude install ia32-libs
 +
</pre>
 +
While my toolchain may have had no external library dependencies it turns out that '''execve''' wouldn't even attempt to load and run a exec a 32-bit ELF binary. The error message '''No such file or directory''' is very misleading.

Latest revision as of 14:25, 15 April 2011


Almost all source packages use the "./configure && make && make install" idiom. This is well and fine, but most of the "configure" scripts were generated with `autoconf` on 32-bit machines. You may see this error when you try to build a package from source on 64-bit Linux:

 /usr/lib/libpopt.so: could not read symbols: File in wrong format

Simply regenerate the "configure" script:

 autoreconf -f -i

Then try the ancient incantation again:

 ./configure && make && make install

32-bit binaries won't run on 64-bit machines

This is an annoying problem because the error messages are very misleading. When I was trying to use a crosscompiler toolchain built for 32-bit Linux under a 64-bit kernel I would get this following error:

$ mips-linux-uclibc-gcc
-bash: mips-linux-uclibc-gcc: No such file or directory

I could see that the executable was in my path and the execute permissions were set. Even if I gave the full path to the executable I would get an error saying "No such file or directory". I ran the binary under `strace` and it fail at the very first instruction execve("./mips-linux-uclibc-gcc", ["./mips-linux-uclibc-gcc"], [/* 41 vars */]) = -1 ENOENT (No such file or directory). I knew that mips-linux-uclibc-gcc wasn't breaking down on some missing or broken library dependency because toolchains by their nature tend to be built with their libraries statically linked. This way a toolchain can be reused on other machines without worrying about dependencies, and you don't have to wonder if different versions of libraries might result in different code being emitte. A quick check with `ldd` showed no external library dependencies.

$ ldd mips-linux-uclibc-gcc
        not a dynamic executable

Eventually I figured out that my system was entirely missing 32bit support. Installing it under Ubuntu was as simple as running:

aptitude install ia32-libs

While my toolchain may have had no external library dependencies it turns out that execve wouldn't even attempt to load and run a exec a 32-bit ELF binary. The error message No such file or directory is very misleading.