On Thu, 04 Jun 2015 16:47:48 -0500, Joe Chisolm wrote:> On Thu, 04 Jun 2015 14:52:50 -0500, Tim Wescott wrote: > >> On Thu, 04 Jun 2015 15:36:34 -0400, DJ Delorie wrote: >> >>> Tim Wescott <seemywebsite@myfooter.really> writes: >>>> Clues for the clueless? >>> >>> 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 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. > > 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 befound.> > 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.$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 http://www.wescottdesign.com
OT, Linux: bash can't see a file that's there, really!
Started by ●June 4, 2015
Reply by ●June 4, 20152015-06-04
Reply by ●June 4, 20152015-06-04
On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote:> > $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? >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 by ●June 4, 20152015-06-04
On Thu, 04 Jun 2015 22:29:01 +0000, Simon Clubley wrote:> On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote: >> >> $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? >> >> > 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.$ 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 http://www.wescottdesign.com
Reply by ●June 4, 20152015-06-04
Tim Wescott <seemywebsite@myfooter.really> writes:> /usr/share/arm-none-eabi/bin/arm-none-eabi-gcc: ELF 32-bit LSB > executableIt'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 by ●June 5, 20152015-06-05
On 05/06/15 00:35, Tim Wescott wrote:> On Thu, 04 Jun 2015 22:29:01 +0000, Simon Clubley wrote: > >> On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote: >>> >>> $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? >>> >>> >> 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. > > $ 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 >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 by ●June 5, 20152015-06-05
Nils M Holm <news2009@t3x.org> wrote:> Tim Wescott <seemywebsite@myfooter.really> wrote: > > $ /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 > > 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.So Linux has this too, now: https://refspecs.linuxfoundation.org/LSB_1.2.0/gLSB/noteabitag.html 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 by ●June 5, 20152015-06-05
On Fri, 05 Jun 2015 08:54:30 +0200, David Brown wrote:> On 05/06/15 00:35, Tim Wescott wrote: >> On Thu, 04 Jun 2015 22:29:01 +0000, Simon Clubley wrote: >> >>> On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote: >>>> >>>> $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? >>>> >>>> >>> 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. >> >> $ 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 >> >> > 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?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)> 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.)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 http://www.wescottdesign.com
Reply by ●June 5, 20152015-06-05
On 05/06/15 09:38, Tim Wescott wrote:> On Fri, 05 Jun 2015 08:54:30 +0200, David Brown wrote: > >> On 05/06/15 00:35, Tim Wescott wrote: >>> On Thu, 04 Jun 2015 22:29:01 +0000, Simon Clubley wrote: >>> >>>> On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote: >>>>> >>>>> $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? >>>>> >>>>> >>>> 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. >>> >>> $ 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 >>> >>> >> 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? > > 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) >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: <http://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit> 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!>> 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.) > > 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. >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 by ●June 5, 20152015-06-05
On Thu, 04 Jun 2015 17:35:46 -0500, Tim Wescott wrote:> On Thu, 04 Jun 2015 22:29:01 +0000, Simon Clubley wrote: > >> On 2015-06-04, Tim Wescott <seemywebsite@myfooter.really> wrote: >>> >>> $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? >>> >>> >> 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. > > $ 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, strippedHow 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 by ●June 5, 20152015-06-05
Tim Wescott <tim@seemywebsite.com> writes:> 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.This answer covers a very similar case, specifically running Google's 32-bit adb on 64-bit Ubuntu 14.04: https://askubuntu.com/questions/454253/how-to-run-32-bit-app-in-ubuntu-64-bit 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.
