bash can't find executable which exists.

krafczyk · 08-06-2012, 08:35 AM

This is a rather complex situation and I'll happily accept somebody telling me a better way to do any part of this.

1. I have to use an old version of gcc (4.1), so I built and installed it into a subdirectory which does not interfere with the versions which I've had ubuntu install. (4.4,4.5,4.6)

2. Upon using this compiler by adjusting the /usr/bin/g{cc,++,fortran} links to the gcc 4.1 versions, I found that many times the wrong libstdc++ was being linked against causing symbol lookup errors. To solve this problem (and avoid using LD_LIBRARY_PATH and LD_RUN_PATH) I decided to use the a gcc specs file to add the correct run path at the linking stage. I did this by using a perl script to add the spec file argument before all other arguments passed to the various gcc compilers.

Perl script:

Code:

#!/usr/bin/perl

exec('/usr/local/src/gnu/gcc/4.1/install/bin/gcc-4.1','-specs=/usr/local/src/gnu/gcc/4.1/install/bin/specs_file',@ARGV);

Specs file:

Code:

%rename link  old_link
 
*link:
-rpath=/usr/local/src/gnu/gcc/4.1/install/lib64 %{old_link}

3. Now for the problem. When I try to compile a simple hello world test,

test program:

Code:

#include "stdio.h"
int main()
{
        printf("Hello world!");
        return 0;
}

I find that I cannot execute the output './a.out' because bash thinks it doesn't exist! Below I've attached several diagnostic commands which show that a.out compiled correctly, exists, it's linked properly and yet bash won't execute it. I've also included two commands which I've read can help diagnose the problem, but that I don't really understand what they say, and am hoping someone else who reads this will understand.

Code:

matthew@sibelius:~$ gcc comptest.c
matthew@sibelius:~$ ./a.out
bash: ./a.out: No such file or directory
matthew@sibelius:~$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped
matthew@sibelius:~$ ldd a.out
	linux-vdso.so.1 =>  (0x00007fff4fdff000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f5f168d8000)
	/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f5f16cbb000)
matthew@sibelius:~$ hd a.out | head
00000000  7f 45 4c 46 02 01 01 00  00 00 00 00 00 00 00 00  |.ELF............|
00000010  02 00 3e 00 01 00 00 00  a0 03 40 00 00 00 00 00  |..>.......@.....|
00000020  40 00 00 00 00 00 00 00  88 09 00 00 00 00 00 00  |@...............|
00000030  00 00 00 00 40 00 38 00  07 00 40 00 1c 00 19 00  |....@.8...@.....|
00000040  06 00 00 00 05 00 00 00  40 00 00 00 00 00 00 00  |........@.......|
00000050  40 00 40 00 00 00 00 00  40 00 40 00 00 00 00 00  |@.@.....@.@.....|
00000060  88 01 00 00 00 00 00 00  88 01 00 00 00 00 00 00  |................|
00000070  08 00 00 00 00 00 00 00  03 00 00 00 04 00 00 00  |................|
00000080  c8 01 00 00 00 00 00 00  c8 01 40 00 00 00 00 00  |..........@.....|
00000090  c8 01 40 00 00 00 00 00  0f 00 00 00 00 00 00 00  |..@.............|
matthew@sibelius:~$ strace ./a.out 2> ls.t; cat ls.t
execve("./a.out", ["./a.out"], [/* 38 vars */]) = -1 ENOENT (No such file or directory)
dup(2)                                  = 3
fcntl(3, F_GETFL)                       = 0x8001 (flags O_WRONLY|O_LARGEFILE)
close(3)                                = 0
write(2, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
exit_group(1)                           = ?

So please, can someone tell me what is going wrong here?

Sidicas · 08-07-2012, 04:49 AM

I had this really wonky thing happen to me when I upgraded from Debian Squeeze to Debian Wheezy... The dist-upgrade finished, I did a reboot, only to find that I couldn't execute anything in the current directory even though the files were chmod'd to be executable. It just couldn't find the file in the current directory even with ./

I could only execute things if I typed in the fully qualified path (/home/david/test.sh). I did another apt-get update and apt-get dist-upgrade.. Installed a bunch more stuff, rebooted and after that it was fixed.. Sorry, I'm sure that's probably not much help to you.

The only thing of this that still remains is that if there is an executable for a difference architecture in the current folder, and even if it's set as executable, the filesystem simply pretends that it doesn't see it.. This is still the case in Debian wheezy and I'm not sure what to make of it.. I want to file a bug, but then again, I realized that the executable I was running was compiled for a different architecture (AMD64 executable on an i386 system) which I guess would just segfault anyway.

I'm positive that in Debian Lenny (years ago), it would try to run it no matter what and then just segfault or throw an error. Now it just pretends that it doesn't see the file, if the file is executable and for a different architecture. It gives a very confusing error message saying it can't find the file when it's clearly right there in the folder and executable.

Have you tried adding both AMD64 and i386 to your architecture? Debian is moving towards "multi-architecture" and looking to get rid of the ia32-libs package which is ridiculously large and full of redundant libs. This might be something related to the move to MultiArch as a *LOT* of libs are getting shuffled around during this transition.

Such strange stuff.. Hope that helps... Or at the very least puts you on the right path to finding a solution.. Maybe there is nothing wrong with your binary and the problems is with your distro installation.

sundialsvcs · 08-07-2012, 07:54 PM

Remember that the file, a.out or otherwise, must be marked as executable.

impert · 08-08-2012, 04:57 PM

This sounds like a 32-bit app on a 64-bit machine problem. If so,
this link:
Running 32-bit applicatiions on 64-bit GNU/Linux Debian should help.

krafczyk · 08-08-2012, 08:34 PM

Thanks for the responses, but unfortunately neither can be the solution to my problem..

I'm running a 64bit system, and the gcc 4.1 compiler I'm using is built for 64 bit compilation. I did not add cross-compilation support.

In addition, you may see with the output of the following commands that the output of gcc is of course set to be executable.

Code:

matthew@sibelius:~$ gcc comptest.c 
matthew@sibelius:~$ ./a.out 
bash: ./a.out: No such file or directory
matthew@sibelius:~$ ls -l | grep a.out
-rwxrwxr-x  1 matthew matthew     6197 Aug  9 03:33 a.out
matthew@sibelius:~$ file a.out
a.out: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, not stripped
matthew@sibelius:~$ ldd a.out
	linux-vdso.so.1 =>  (0x00007fffc994b000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f85940c3000)
	/lib/ld64.so.1 => /lib64/ld-linux-x86-64.so.2 (0x00007f85944a6000)

chrism01 · 08-09-2012, 12:21 AM

I think maybe this would be better off in the Programming Forum, given what you are asking.
You can use the Report button to ask the Mods to move it.