I'm getting a "No such file or Directory" error when I attempt to run a 32-bit binary executable in 64-bit environment from a bash shell. Bash exit code 127.

Yet when I attempt to run 64-bit binary executable in a 32-bit environment I get a more expected "Cannot execute binary file" error. Bash exit code 126.

I got similar results running this test in /bin/csh with "Command not found" instead of the expected "Exec format error. Binary file not executable" error.

Does anyone know if this happens in other Linux distributions or is Slackware special with a more pure 64 bit environment?

I set up a dual boot system running vanilla 14.1 versions of Slackware32 and Slackware64 to test this with a simple "hello" program in C. I first noticed this misleading error on a Slackware64 13.37 system upgraded to 14.0 with standard security updates applied.

It's not a show-stopper and easy to work around but perhaps this is something than can be "fixed" to generate a more appropriate error in a future release.

Did you load the infamous 32 bit compat libraries from Alien Bob without which you are limited to the 64 bit variety of wholesome Slackware goodness?
If not, be about it my good man....

1 members found this post helpful.

i think the error refers to a missing 32bit ld, rather then the file itself missing

how i know it;
shell tells the kernel to exec to execute the 32bit program
the kernel loads it, starts and all that
then the binary tries to run the linker specified in the ELF (aka interpreter, from the ELF's standpoint)
and there is no such file

i agree, "no ELF interpreter found" would be clearer

1 members found this post helpful.

@dijetlo: The 32-bit binary executable should NOT run in a 64-bit environment. It fails as expected, but gives unexpected failure information.

I was also thinking that another file in the loading/execution process was missing and the return code was merely being passed to the shell which then returns the misleading failure information. I'm not familiar with the process so and didn't want to complicate the original post.

I was also wondering if different options in building the shells in Slackware64 or a "dummy" version of the expected file would result in a better return code. I just tried my simple test with a Korn shell and got the same results.

It's a minor issue but perhaps something that can be improved since that Slackware32 reports better failure information.

I just checked and the files in /source/a/bash for Slackware64-14.1 are hard links targeting those in Slackware-14.1, patches included, so that pretty much rules out a difference in the respective builds, I assume.

Also, output of "shopt -p" are genuinely identical.

So yes, probably the issue comes from elsewhere.

The amd64 architecture (or better: the amd64 extension to the IA32 architecture) was specifically designed to be backwards compatible with the IA32 architecture, so in fact it is designed to work that way and if you would have a totally self contained 32 bit binary (without need of external libraries) it would work without a problem. That is why you get the errors about missing files, namely the needed libraries for that specific binary.
On the other hand, the IA32 architecture knows nothing about the amd64 extensions and so refuses to run them due to not being able to understand them.

So, actually, both error messages are indeed correct (and as I see it Csh is wrong with the command not found message), that is just the way the system was designed to work.

1 members found this post helpful.

here's a good overview
http://www.ibm.com/developerworks/li...mic-libraries/

in short,
the kernel loads the binary then loads the interpreter (loader, ld) and lets it run
the interpreter starts, loads all the shared libraries then returns control to the program (probably just jumps to _start)

thing is that the interpreter is ran by the kernel itself
so to "fix" this would mean doing it in the kernel
(it is written in .interp section of an ELF file/image)

and a pic of an elf http://imgur.com/a/JEObT#1
this doesn't show but .interp goes in "section names" and "section header table"
also missing is the PLT, a table of library calls (space for a pointer + function name)


PS 32 binary execution can be disabled when compiling the kernel
id be careful though

@Didier Spaier Thanks for helping to confirm that it is unlikely a shell compilation issue.

@TobiSGD your response explains why the "problem" only occurs with a dynamically linked 32-bit executable in a 64-bit environment and not the other way around. Thanks.

I statically linked my hello program and the resulting 32-bit statically linked executable ran just fine in the 64-bit environment as there were no (non-existent 32-bit) libraries to load.

@genss Thanks for the IBM link explaining the process in detail. When I have time I may try recompiling the kernel with the 32-bit binary disabled for fun. A quick search showed the following may be involved: CONFIG_X86_32, CONFIG_OUTPUT_FORMAT, CONFIG_ARCH_DEFCONFIG. I'll probably discover that I can't even get to a login prompt with it disabled.

----

I imagine a kernel or shell developer response to my issue of misleading failure information when running a dynamically linked executable without the proper environment and without the required shared libraries is probably "Don't do that!".

IA32_EMULATION to "n" should do the job

my money's on almost everything running fine
gl

Load the compat libs and see if it works.
I know you think we know crap but I would point out it aint our stuff that's busted.

??????

I received a good response from LQ on this issue and am now more educated on this issue and better understand the Slackware Linux environment. I've marked this thread as SOLVED (before your post quoted above) as I think the important aspects of my "problem" have been explained.

In other words, I'm a happy customer.

Yeah, then perhaps we're not a good match. I just come here to fix stuff because of a personality fault I can't seem to get past. I'm sorry if I get a little drilled in on resolutions and don't recognize when someone is exporing a theoretical question.
Theoretical questions give me gas, as a general rule. I just like it when the little lights blink like they're supposed to.
Again, sorry for any offense, I appear to be in something of a snit at the moment.