executing binary file: file not found

Question

I know there are similar questions out there, but I haven't found a solution nor this exact case. The binary was built on Arch Linux using its GCC 4.7. The package works fine on the build system. The commands below were executed on:

Linux vbox-ubuntu 3.2.0-29-generic #46-Ubuntu SMP Fri Jul 27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

The file in question is located here. It's a Linux 64-bit to Windows 64-bit cross-compiler. Untarring it to ~/ gives a single ~/mingw64 directory which contains everything needed.

When I try to run ~/mingw64/x86_64-w64-mingw32/bin/as this is what I get:

bash: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: No such file or directory 

Running file ~/mingw64/x86_64-w64-mingw32/bin/as gives me:

/home/ruben/mingw64/x86_64-w64-mingw32/bin/as: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.32, BuildID[sha1]=0x0b8e50955e7919b76967bac042f49c5876804248, not stripped 

Running ldd ~/mingw64/x86_64-w64-mingw32/bin/as gives me:

 linux-vdso.so.1 => (0x00007fff3e367000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2ceae7e000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2ceaac1000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f2ceb0a8000) 

I am truly at a loss. Any help is much appreciated.

EDIT: Some more details: The build system is Arch Linux (currently glibc 2.16). The output of ls -l is:

-rwxr-xr-x 2 ruben users 1506464 11 aug 23:49 /home/ruben/mingw64/bin/x86_64-w64-mingw32-as 

The output of objdump -p is:

Version References: required from libz.so.1: 0x0827e5c0 0x00 05 ZLIB_1.2.0 required from libc.so.6: 0x0d696917 0x00 06 GLIBC_2.7 0x06969194 0x00 04 GLIBC_2.14 0x0d696913 0x00 03 GLIBC_2.3 0x09691a75 0x00 02 GLIBC_2.2.5 

The output of ldd -v on Ubuntu 12.04 is:

 linux-vdso.so.1 => (0x00007fff225ff000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fd525c71000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fd5258b4000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007fd525e9b000) Version information: /home/ruben/mingw64/x86_64-w64-mingw32/bin/as: libz.so.1 (ZLIB_1.2.0) => /lib/x86_64-linux-gnu/libz.so.1 libc.so.6 (GLIBC_2.7) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.14) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.3) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libz.so.1: libc.so.6 (GLIBC_2.3.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.4) => /lib/x86_64-linux-gnu/libc.so.6 libc.so.6 (GLIBC_2.2.5) => /lib/x86_64-linux-gnu/libc.so.6 /lib/x86_64-linux-gnu/libc.so.6: ld-linux-x86-64.so.2 (GLIBC_2.3) => /lib64/ld-linux-x86-64.so.2 ld-linux-x86-64.so.2 (GLIBC_PRIVATE) => /lib64/ld-linux-x86-64.so.2 

The tested other OSes are Fedora 17 (glibc 2.15) and Ubuntu 12.04 (eglibc 2.15). Both zlib and glibc version requirements are met.

Answer 1

If I run ldd -v as on my system, I get:

./as: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.14' not found (required by ./as) linux-vdso.so.1 => (0x00007fff89ab1000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f1e4c81f000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e4c498000) /lib/ld-linux-x86-64.so.2 => /lib64/ld-linux-x86-64.so.2 (0x00007f1e4ca6d000) 

So yeah, it looks like these binaries are looking for a GLIBC_2.14 symbol, which you are presumably missing on your system. As svenx pointed out, it looks like it's searching for the memcpy@@GLIBC_2.14 symbol. Some more information on why memcpy was given a new version is described in this bug report.

Installing a new version of glibc on your target system should fix it. If you want to try to rebuild the binary to still work on the old version of glibc, you could try tricks like the one listed here. You could also maybe get by with a shim that just provides the specific version of the memcpy symbol that you need, but that gets to be a bit hacky.

---

After reading your update: you're right, that wasn't your problem. But I think I've found it: your binary is requesting the interpreter /lib/ld-linux-x86-64.so.2, which doesn't exist on Ubuntu 12.04 systems:

$ readelf -a ./as | grep interpreter [Requesting program interpreter: /lib/ld-linux-x86-64.so.2] 

While ldd knew to find it in /lib64 instead, I suppose the kernel doesn't know that when it tries to run the binary and can't find the file's requested interpreter. You could try just running it through the interpreter manually:

$ pwd /home/jim/mingw64/x86_64-w64-mingw32/bin $ ./as --version -bash: ./as: No such file or directory $ /lib64/ld-linux-x86-64.so.2 ./as --version GNU assembler (rubenvb-4.7.1-1-release) 2.23.51.20120808 Copyright 2012 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or later. This program has absolutely no warranty. This assembler was configured for a target of `x86_64-w64-mingw32'. 

I'm not 100% certain this is working correctly -- on my system, running gcc this way gives a segmentation fault. But that's at least a different problem.

Answer 2

Your problem is a variant of Getting "Not found" message when running a 32-bit binary on a 64-bit system: you have an executable that mentions a dynamic loader that is not there.

In your case, the dynamic loader /lib/ld-linux-x86-64.so.2 exists but in a different location /lib64/ld-linux-x86-64.so.2. The simplest way to make your programs work would be to create a symbolic link:

ln -s ../lib64/ld-linux-x86-64.so.2 /lib/