OT, Linux: bash can't see a file that's there, really!

Sorry for the OT post, but I figure I'll get a quicker, more useful response here.

Brand new computer, Xubuntu 14.04 instead of Lubuntu 12.04

I just copied over my Codesourcery directory to /usr/share/arm-none-eabi (where it was on the old machine, and where everything worked fine).

Bash insists it's not there, even though I can see it in a directory:

Here's ls:

$ ls -l /usr/share/arm-none-eabi/bin/*gcc

-rwxr-xr-x 1 root root 270608 Aug 6 2014 /usr/share/arm-none-eabi/bin/ arm-none-eabi-gcc

Here's when I try to run it:

$ /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc bash: /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc: No such file or directory

Clues for the clueless?

Thanks.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott
Loading thread data ...

Non-printing character in filename? In FreeBSD, "ls -B" (or "ls -b" for C-esque renderings) is your friend.

Reply to
Don Y

ls -B /usr/share/arm-none-eabi/bin/*gcc /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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
Reply to
Nils M Holm

Do, presumably, you can rm(1), mv(1), etc. successfully.

What does file(1) claim? And, nm(1)?

Reply to
Don Y

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.

Reply to
DJ Delorie

The error message was that bash didn't see the file itself, not that it couldn't find the library.

But -- maybe. Particularly since it's a 64-bit linux, and the old one was 32.

--
www.wescottdesign.com
Reply to
Tim Wescott

+1 on ldd. I've had this happen before. ldd will show you what is missing.
--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

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] . . .

Reply to
DJ Delorie

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.

--
Chisolm 
Republic of Texas
Reply to
Joe Chisolm

found.

$ldd /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc not a dynamic executable

That seems more direct. Is it a 32-bit vs. 64-bit thing?

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

I haven't seen the results of running "file" on this executable posted yet.

(Apologies if you have already done this and I have missed it.)

Simon.

--
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP 
Microsoft: Bringing you 1980s technology to a 21st century world
Reply to
Simon Clubley

$ file /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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.

Reply to
DJ Delorie

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.)

Reply to
David Brown

So Linux has this too, now:

formatting link

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
Reply to
Nils M Holm

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.

Snivel. Whine. Etc.

--
Tim Wescott 
Wescott Design Services 
 Click to see the full signature
Reply to
Tim Wescott

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.

The suggestion I saw on the web was this:

Roughly:

sudo dpkg --add-architecture i386 sudo apt-get update sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

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:

/opt/Freescale/KDS_2.0.0/toolchain/bin/arm-none-eabi-gcc

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.)

Reply to
David Brown

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).

Reply to
Aleksandar Kuktin

This answer covers a very similar case, specifically running Google's

32-bit adb on 64-bit Ubuntu 14.04:

formatting link

It seems to come down to just running

sudo dpkg --add-architecture i386

and then installing some common libs:

sudo apt-get update sudo apt-get install libc6:i386 libncurses5:i386 libstdc++6:i386

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.

Reply to
Anssi Saari

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.