Wrong ELF ABI tag? Missing ELF ABI-tag note section?
Had this on many BSD's recently. Linking an executable without a note section identifying the ABI results in a non-executable executable.
In this case, it would probably be easiest to get a newer binary version. Or use elfdump or a similar tool to find out in which way the binary differs from the system binaries. You could then try to tweak the binary with an interactive ELF editor.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Try "type /usr/share/arm-none-eabi/bin/*gcc" and "ldd /usr/share/arm-none-eabi/bin/*gcc" - it might be that the older binaries were built against older libraries and/or dynamic linkers, so yu may need to install a compatibility package to run them as-is.
Just because you copied the *gcc file, doesn't mean Linux has all the support files (/lib/ld.so.1, /lib/libc.so.*, etc) and the error message might be from one of those.
The error message says that, but sometimes it lies. When Linux runs an ELF binary, that binary usually needs a "dynamic loader" to run *also*, which resolves all the shared library stuff. Much like a script needs its interpreter, ELF binaries need their loader. If the loader doesn't exist, the kernel might return "not found" when you try to run that binary. bash: "Please run this", kernel: "I couldn't find one of the files I need to do so".
Strange but true.
$ readelf -l /usr/bin/gcc
. . . INTERP 0x00000000000002a8 0x00000000004002a8 0x00000000004002a8 0x000000000000001c 0x000000000000001c R 1 [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] . . .
From the man page for execve(2) ENOENT The file filename or a script or ELF interpreter does not exist, or a shared library needed for file or interpreter cannot be found.
This error is going to percolate up to bash so you get the "No such file or directory" because, most likely, a shared library is not found. ldd will tell you what is missing.
It's probably a 32-bit thing. In Fedora, for example, you have to separately install the 32-bit runtime on a 64-bit system, I suspect either (1) you have to do that also for Ubuntu, or (2) the dynamic loader it's looking for is older than the one you've installed. That readelf command would tell you what it's looking for, then you can see if you have a different version of that file installed.
As DJ says, it is likely that you are missing the 32-bit libraries on the 64-bit system. Is this a newly installed system?
There should not be any problems running 32-bit binaries once the libraries are installed - your distro should have them in its repositories (using the package manager, software control centre, yum, apt-get, or whatever you usually use). If you don't know how to do it, and google doesn't find an answer quickly, let us know which distro you are using.
(Note - some distros have libraries in x64-64, i386/i686 and x32 versions. It's the i386/i686 version you want here. x32 is a rather cool ABI for using the extra registers and features of amd64 cpus but with compact and efficient 32-bit addresses.)
Note that if it would be an ldd issue, you would probably get a different message (like "some.so.x not found"). Since the message comes from bash, the file is not executable at all, which is exactly what happens on BSD when the ELF ABI-tag is missing. I assume that Linux execve() would handle it in the same way.
--
Nils M Holm < n m h @ t 3 x . o r g > www.t3x.org
Yes, it's a brand-new Ubuntu 14.04 64-bit install. I copied over the files from my Ubuntu 32-bit system (where they just worked, after unzipping the file from CodeSourcery)
I should probably start a new thread, but I'm at a minor impasse, and trying to figure out what to do for my embedded arm compilation needs. Ubuntu has the arm-none-eabi tools, but the dgb-arm-none-eabi package won't install because it tries to overwrite the man files for the regular ol' gdb (somebody done messed up out there in package-manager land). I have not yet checked the CodeSourcery site -- that's what's been working for me, and if they have something current for 64-bit Debian, that'll probably work for me. My final alternative is to try to build from source, but I can't even quite remember the name of the script that was floating around out there to make it easy, and IIRC the maintainer had more or less dropped it.
With such copying, or manual installation, the package manager doesn't know that you need to install the 32-bit libraries. If you had installed a 32-bit program with "apt-get" (or other system tools), the libraries could be installed automatically.
That installs some basic 32-bit libraries, which are probably enough for the compiler. Of course, if you want to run CodeSourcery's eclipse with packaged JVM, you will need a lot more 32-bit libraries.
A quick way to get a fair number of these libraries would be to install a 32-bit app from the Ubuntu package manager - something like Skype should work.
Another option would be just to get the 64-bit packages from Code Sourcery!
I strongly dislike getting embedded compilers from a distribution. It's okay for things like gdb or openocd, but not for the compiler or library. When I am working on a project, I need to know that the compiler and library is the same regardless of the machine, the distro, or the version of the system - I don't want an "apt-get upgrade" to change my embedded compiler!
So I make a point of keeping all my embedded compilers separated. For example, at the moment I am using a compiler from here:
The installation is independent of the distro and system.
(I do a similar thing on Windows - I truly /hate/ when an installation such as AVR Studio insists on "upgrading" an existing installation, instead of installing it in parallel.)
How about tracing the problem, one step at a time?
File tells us the the executable is a shared executable. Let's find out what dynamic linker it uses. Output of `readelf -a | grep interpreter' will give us that information. Then we will try to find the linker (which probably does not exist - if a library is missing, bash reports a different error IIRC).
I dunno, I don't remember having to install anything extra on my Ubuntu laptop to run 32-bit apps... Or maybe they got installed as a dependency for something else like Steam.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.