[SOLVED] Program is there, but bash can't find it

71GA · 2014-12-04 07:43:57

I moved my programs which I need for ARM crosscompiling into "/opt/ARM/cs_lite/bin". I added this path into PATH:

[dominik@localhost ~]$ echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/opt/ARM/cs_lite/bin:/opt/ARM/unsimgcr

Nevertheless if I try to execute program "arm-none-eabi-as" I get an error:

[dominik@localhost ~]$ arm-none-eabi-as 
bash: /opt/ARM/cs_lite/bin/arm-none-eabi-as: No such file or directory

All the binaries inside "/opt/ARM/cs_lite/bin" have rights to execute:

[dominik@localhost bin]$ ls -l
total 17900
-rwxrwxrwx 1 root root  569980 Nov  4  2010 arm-none-eabi-addr2line
-rwxrwxrwx 2 root root  593396 Nov  4  2010 arm-none-eabi-ar
-rwxrwxrwx 2 root root 1046336 Nov  4  2010 arm-none-eabi-as
-rwxrwxrwx 2 root root  223492 Nov  4  2010 arm-none-eabi-c++
-rwxrwxrwx 1 root root  572028 Nov  4  2010 arm-none-eabi-c++filt
-rwxrwxrwx 1 root root  222180 Nov  4  2010 arm-none-eabi-cpp
-rwxrwxrwx 1 root root   18612 Nov  4  2010 arm-none-eabi-elfedit
-rwxrwxrwx 2 root root  223492 Nov  4  2010 arm-none-eabi-g++
-rwxrwxrwx 2 root root  220612 Nov  4  2010 arm-none-eabi-gcc
-rwxrwxrwx 2 root root  220612 Nov  4  2010 arm-none-eabi-gcc-4.5.1
-rwxrwxrwx 1 root root   26812 Nov  4  2010 arm-none-eabi-gcov
-rwxrwxrwx 1 root root 3378600 Nov  4  2010 arm-none-eabi-gdb
-rwxrwxrwx 1 root root 3378600 Nov  4  2010 arm-none-eabi-gdbtui
-rwxrwxrwx 1 root root  631072 Nov  4  2010 arm-none-eabi-gprof
-rwxrwxrwx 2 root root  844608 Nov  4  2010 arm-none-eabi-ld
-rwxrwxrwx 2 root root  579356 Nov  4  2010 arm-none-eabi-nm
-rwxrwxrwx 2 root root  727096 Nov  4  2010 arm-none-eabi-objcopy
-rwxrwxrwx 2 root root  866236 Nov  4  2010 arm-none-eabi-objdump
-rwxrwxrwx 2 root root  593428 Nov  4  2010 arm-none-eabi-ranlib
-rwxrwxrwx 1 root root  340780 Nov  4  2010 arm-none-eabi-readelf
-rwxrwxrwx 1 root root  771476 Nov  4  2010 arm-none-eabi-run
-rwxrwxrwx 1 root root  572288 Nov  4  2010 arm-none-eabi-size
-rwxrwxrwx 1 root root  363316 Nov  4  2010 arm-none-eabi-sprite
-rwxrwxrwx 1 root root  572220 Nov  4  2010 arm-none-eabi-strings
-rwxrwxrwx 2 root root  727096 Nov  4  2010 arm-none-eabi-strip

Why doesn't bash see my executables?

Last edited by 71GA (2014-12-05 11:32:48)

ooo · 2014-12-04 07:59:55

71GA wrote:

Nevertheless if I try to execute program "arm-none-eabi-as" I get an error:
[dominik@localhost ~]$ arm-none-eabi-as 
bash: /opt/ARM/cs_lite/bin/arm-none-eabi-as: No such file or directory
...
Why doesn't bash see my executables?

Actually it sees them, as it tries to execute the file from the location in your path.
IIRC you get the 'No such file or directory' error if you're trying to execute a file with wrong binary format, e.g. ARM binary on x86, so I'm guessing that's the situation here.

drcouzelis · 2014-12-04 08:09:53

71GA wrote:

[dominik@localhost ~]$ arm-none-eabi-as 
bash: /opt/ARM/cs_lite/bin/arm-none-eabi-as: No such file or directory

Why doesn't bash see my executables?

Thanks to that error message, you know that Bash does see your executables (I mean, it's not a PATH problem).

What type of file are you trying to run? What is the output of this command:

file /opt/ARM/cs_lite/bin/arm-none-eabi-as

On what partition is "/opt"? What is the output of:

mount

Also, why are the permissions so strange (777)?

Last edited by drcouzelis (2014-12-04 08:10:24)

71GA · 2014-12-04 08:35:29

Here is the type of that file - it is a compiler for cross compilation to ARM architecture. This shouldn't be a problem or perhaps if multilib repository isn't installed!? Which package would enable me to run 32-bit software on 64-bit PC is it enough to enable multilib repo in /etc/pacman.conf?

[dominik@localhost bin]$ file /opt/ARM/cs_lite/bin/arm-none-eabi-as
/opt/ARM/cs_lite/bin/arm-none-eabi-as: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped

Permissions are so strange because at first I thought that they were causing this and I granted them every rights with chmod. Well obviously they aren't the cause.

Here is the mount output:

[dominik@localhost bin]$ mount                                                                                                                                                      
proc on /proc type proc (rw,nosuid,nodev,noexec,relatime)                                                                                                                          
sys on /sys type sysfs (rw,nosuid,nodev,noexec,relatime)                                                                                                                            
dev on /dev type devtmpfs (rw,nosuid,relatime,size=503512k,nr_inodes=125878,mode=755)                                                                                              
run on /run type tmpfs (rw,nosuid,nodev,relatime,mode=755)                                                                                                                          
/dev/sda2 on / type ext4 (rw,noatime,data=ordered)                                                                                                                                  
securityfs on /sys/kernel/security type securityfs (rw,nosuid,nodev,noexec,relatime)                                                                                                
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)                                                                                                                                      
devpts on /dev/pts type devpts (rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000)                                                                                              
tmpfs on /sys/fs/cgroup type tmpfs (ro,nosuid,nodev,noexec,mode=755)                                                                                                                
cgroup on /sys/fs/cgroup/systemd type cgroup (rw,nosuid,nodev,noexec,relatime,xattr,release_agent=/usr/lib/systemd/systemd-cgroups-agent,name=systemd)
pstore on /sys/fs/pstore type pstore (rw,nosuid,nodev,noexec,relatime)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,nosuid,nodev,noexec,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu,cpuacct type cgroup (rw,nosuid,nodev,noexec,relatime,cpu,cpuacct)
cgroup on /sys/fs/cgroup/memory type cgroup (rw,nosuid,nodev,noexec,relatime,memory)
cgroup on /sys/fs/cgroup/devices type cgroup (rw,nosuid,nodev,noexec,relatime,devices)
cgroup on /sys/fs/cgroup/freezer type cgroup (rw,nosuid,nodev,noexec,relatime,freezer)
cgroup on /sys/fs/cgroup/net_cls type cgroup (rw,nosuid,nodev,noexec,relatime,net_cls)
cgroup on /sys/fs/cgroup/blkio type cgroup (rw,nosuid,nodev,noexec,relatime,blkio)
systemd-1 on /proc/sys/fs/binfmt_misc type autofs (rw,relatime,fd=22,pgrp=1,timeout=300,minproto=5,maxproto=5,direct)
hugetlbfs on /dev/hugepages type hugetlbfs (rw,relatime)
debugfs on /sys/kernel/debug type debugfs (rw,relatime)
configfs on /sys/kernel/config type configfs (rw,relatime)
mqueue on /dev/mqueue type mqueue (rw,relatime)
tmpfs on /tmp type tmpfs (rw)
/dev/sda5 on /boot type ext4 (rw,noatime,data=ordered)
tmpfs on /run/user/1000 type tmpfs (rw,nosuid,nodev,relatime,size=101260k,mode=700,uid=1000,gid=100)
/dev/sdb1 on /run/media/dominik/INTENSO type vfat (rw,nosuid,nodev,relatime,uid=1000,gid=100,fmask=0022,dmask=0077,codepage=437,iocharset=iso8859-1,shortname=mixed,showexec,utf8,flush,errors=remount-ro,uhelper=udisks2)

Last edited by 71GA (2014-12-04 09:29:38)

drcouzelis · 2014-12-04 12:53:06

71GA wrote:

Here is the type of that file - it is a compiler for cross compilation to ARM architecture. This shouldn't be a problem or perhaps if multilib repository isn't installed!? Which package would enable me to run 32-bit software on 64-bit PC is it enough to enable multilib repo in /etc/pacman.conf?
[dominik@localhost bin]$ file /opt/ARM/cs_lite/bin/arm-none-eabi-as
/opt/ARM/cs_lite/bin/arm-none-eabi-as: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped

This looks like the problem to me. You are trying to run a 32 application on a 64 bit operating system, which is possible. But I think Arch Linux is configured to run "i686" applications and not "80386". And was this really compiled for Linux 2.2? That is amazingly old, so that might be an issue too.

No, simply enabling [multilib] will not fix anything. The application also requires the 32 bit versions of the libraries it needs, which CAN be installed from [multilib]. I'm not sure how to figure out which libraries you need (maybe with the "ldd" command).

Please understand that I am only speculating as to the reasons why the application will not run. I really don't have much experience with this sort of thing.

Where did you get it from? Is there a version available in either the repositories or the AUR?

EDIT: New ideas!

Try installing "multilib-devel". Maybe? I'm just browsing the FAQ: https://wiki.archlinux.org/index.php/Arch64_FAQ

Last edited by drcouzelis (2014-12-04 13:00:18)

71GA · 2014-12-04 13:06:39

I also believe this is the problem, but these types of file already ran sucessfuly on my laptop pc with specs:

Linux Ziga-laptop 3.16.3-1-ARCH #1 SMP PREEMPT Wed Sep 17 21:54:13 CEST 2014 x86_64 GNU/Linux

So this should work if I install the right libs.

71GA · 2014-12-04 13:08:08

drcouzelis wrote:

EDIT: New ideas!
Try installing "multilib-devel". Maybe? I'm just browsing the FAQ: https://wiki.archlinux.org/index.php/Arch64_FAQ

Will do that ASAP. Currently I am not on my PC. Thank you for your help.

drcouzelis · 2014-12-04 13:34:41

71GA wrote:

these types of file already ran sucessfuly on my laptop pc with [64 bit Arch Linux]

Oh! I see. Then yeah, it should just be a matter of installing the right packages. If you still have that laptop then you can just look and see what's installed.

Trilby · 2014-12-04 13:39:52

The suggestion to run ldd on some of them seems to have been burried above - that seems the best approach to me: find out what you actually need rather than trying to guess and check, or at very least confirm that it is due to missing libs that they binaries expect to find.

71GA · 2014-12-04 16:23:30

Trilby wrote:

The suggestion to run ldd on some of them seems to have been burried above - that seems the best approach to me: find out what you actually need rather than trying to guess and check, or at very least confirm that it is due to missing libs that they binaries expect to find.

True. I forgot about this because of too many brainstorming.

[ziga@Ziga-PC ~]$ ldd /opt/ARM/cs_lite/bin/arm-none-eabi-as 
        linux-gate.so.1 (0xf76eb000)
        libc.so.6 => /usr/lib32/libc.so.6 (0xf74ec000)
        /lib/ld-linux.so.2 (0xf76ee000)

Scimmia · 2014-12-04 16:37:44

71GA wrote:

Here is the type of that file - it is a compiler for cross compilation to ARM architecture. This shouldn't be a problem or perhaps if multilib repository isn't installed!? Which package would enable me to run 32-bit software on 64-bit PC is it enough to enable multilib repo in /etc/pacman.conf?
[dominik@localhost bin]$ file /opt/ARM/cs_lite/bin/arm-none-eabi-as
/opt/ARM/cs_lite/bin/arm-none-eabi-as: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.2.5, stripped

The kernel dropped support for the 80386 architecture with 3.8. I'm betting this is your problem.

drcouzelis · 2014-12-04 17:23:46

Scimmia wrote:

The kernel dropped support for the 80386 architecture with 3.8. I'm betting this is your problem.

I don't know... Linux 3.8 came out in Feb 2013 and 71GA said he was using "these types of files" in 64 bit Arch Linux around Sep 2014.

Scimmia · 2014-12-04 17:28:13

Ah, but "these types of files" does not mean these specific binaries.

ETA: Why aren't you using the tools available in the Community repo? https://www.archlinux.org/packages/?q=arm-none-eabi

Last edited by Scimmia (2014-12-04 17:42:16)

WorMzy · 2014-12-04 17:44:43

Just for the record, "Intel 80386" appears on recently compiled files too (e.g. /usr/lib32/libgfortran.so.3.0.0), so I don't think that has much bearing.

Similarly identified programs run fine on my up-to-date 64-bit machine:

/opt/natinst/LabVIEW-2011/labview: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.22, stripped

The only difference is the Linux version it's "for" (2.2.5 vs 2.6.22). I don't know what determines this, but it's possible that the binaries really are relying on code that is no longer present in the kernel, as Scimmia suggests.

Still, just as a sanity check, is gcc-libs-multilib is installed?

falconindy · 2014-12-05 00:49:20

WorMzy wrote:

The only difference is the Linux version it's "for" (2.2.5 vs 2.6.22). I don't know what determines this, but it's possible that the binaries really are relying on code that is no longer present in the kernel, as Scimmia suggests

It's determined at compile time by glibc

71GA · 2014-12-05 11:32:27

Problem is solved. The only thing we needed was to install package "multilib-devel". Thank you! One more thing is there a way these packages won't be supported soon?

drcouzelis · 2014-12-05 13:38:15

Yay for the wiki! I learned something new too.

71GA wrote:

One more thing is there a way these packages won't be supported soon?

You mean, is there a chance you won't be able to run "arm-none-eabi-as" on Arch Linux soon? I have no idea, but my guess is that if it's still supported even now then support won't be going away any time soon. And if it DOES go away, just use another operating system that does support it, for example, by dual booting Debian.

WorMzy · 2014-12-05 15:49:03

falconindy wrote:

WorMzy wrote:
The only difference is the Linux version it's "for" (2.2.5 vs 2.6.22). I don't know what determines this, but it's possible that the binaries really are relying on code that is no longer present in the kernel, as Scimmia suggests
It's determined at compile time by glibc

Thanks for that. Reading up on that, it seems that the lower the number, the more compatibility code is added, so that was a red herring too.

The only thing we needed was to install package "multilib-devel"

Glad you got it working. Just for the record though, 'multilib-devel' is a group of packages.

anatolik · 2015-02-03 16:55:20

Scimmia wrote:

Why aren't you using the tools available in the Community repo? https://www.archlinux.org/packages/?q=arm-none-eabi

I have the same question. By using standard arm-none-eabi toolset from Arch repos you avoid a lot of problems with dependencies and installation. arm-none-eabi toolset should be used by default. If you see any problems with it - please speak up.

71GA · 2015-02-03 19:29:22

anatolik wrote:

Scimmia wrote:
Why aren't you using the tools available in the Community repo? https://www.archlinux.org/packages/?q=arm-none-eabi
I have the same question. By using standard arm-none-eabi toolset from Arch repos you avoid a lot of problems with dependencies and installation. arm-none-eabi toolset should be used by default. If you see any problems with it - please speak up.

Oh there is a really big problem. The arm-none-eabi toolchain is a more reecent version and mine is older. But newer version wont compile programs for example LPC3141 while older one does it just fine. Thats whyI use older one.

anatolik · 2015-02-03 20:16:43

71GA wrote:

But newer version wont compile programs for example LPC3141 while older one does it just fine.

Interesting.. Could you please provide step-by-step instructions that show the problem?

Also where did you get the toolchain you currently use?

Last edited by anatolik (2015-02-03 20:18:10)

71GA · 2015-02-03 20:18:23

anatolik wrote:

71GA wrote:
But newer version wont compile programs for example LPC3141 while older one does it just fine.
Interesting.. Could you please provide step-by-step instructions that show the problem?

This is very time consuming. I can give you a .zip of a bare-metal project which won't compile.

anatolik · 2015-02-03 20:23:17

71GA wrote:

This is very time consuming. I can give you a .zip of a bare-metal project which won't compile.

This is fine. I'll check the issue and try to figure out why Arch toolset does not work. Maybe your toolset includes non-upstream patches....

What toolset do you use?

71GA · 2015-02-03 20:43:46

Well here is the .tar.gz file with a project. I wrote you an README inside.
I use arm-none-eabi- toolset for baremetal programs.

http://www.2shared.com/file/CDLvIh53/io … uttar.html

Last edited by 71GA (2015-02-03 20:44:14)

anatolik · 2015-02-03 21:00:55

I can build your project with default Arch toolset. The changes I made:

1) "DIRCSLITE := /usr"
2) Set gcc version to "$(LD) -o $@ $^ $(DIRCSLITE)/arm-none-eabi/lib/libc.a $(DIRCSLITE)/lib/gcc/arm-none-eabi/4.9.2/libgcc.a"

The result is

$ ls -l executable_*
-rwxr-xr-x 1 anatol anatol 624 Feb 3 12:57 executable_bin
-rwxr-xr-x 1 anatol anatol 40880 Feb 3 12:57 executable_elf

I do not have a LPC3141 board so I cannot check your program.

Arch Linux

#1 2014-12-04 07:43:57

[SOLVED] Program is there, but bash can't find it

#2 2014-12-04 07:59:55

Re: [SOLVED] Program is there, but bash can't find it

#3 2014-12-04 08:09:53

Re: [SOLVED] Program is there, but bash can't find it

#4 2014-12-04 08:35:29

Re: [SOLVED] Program is there, but bash can't find it

#5 2014-12-04 12:53:06

Re: [SOLVED] Program is there, but bash can't find it

#6 2014-12-04 13:06:39

Re: [SOLVED] Program is there, but bash can't find it

#7 2014-12-04 13:08:08

Re: [SOLVED] Program is there, but bash can't find it

#8 2014-12-04 13:34:41

Re: [SOLVED] Program is there, but bash can't find it

#9 2014-12-04 13:39:52

Re: [SOLVED] Program is there, but bash can't find it

#10 2014-12-04 16:23:30

Re: [SOLVED] Program is there, but bash can't find it

#11 2014-12-04 16:37:44

Re: [SOLVED] Program is there, but bash can't find it

#12 2014-12-04 17:23:46

Re: [SOLVED] Program is there, but bash can't find it

#13 2014-12-04 17:28:13

Re: [SOLVED] Program is there, but bash can't find it

#14 2014-12-04 17:44:43

Re: [SOLVED] Program is there, but bash can't find it

#15 2014-12-05 00:49:20

Re: [SOLVED] Program is there, but bash can't find it

#16 2014-12-05 11:32:27

Re: [SOLVED] Program is there, but bash can't find it

#17 2014-12-05 13:38:15

Re: [SOLVED] Program is there, but bash can't find it

#18 2014-12-05 15:49:03

Re: [SOLVED] Program is there, but bash can't find it

#19 2015-02-03 16:55:20

Re: [SOLVED] Program is there, but bash can't find it

#20 2015-02-03 19:29:22

Re: [SOLVED] Program is there, but bash can't find it

#21 2015-02-03 20:16:43

Re: [SOLVED] Program is there, but bash can't find it

#22 2015-02-03 20:18:23

Re: [SOLVED] Program is there, but bash can't find it

#23 2015-02-03 20:23:17

Re: [SOLVED] Program is there, but bash can't find it

#24 2015-02-03 20:43:46

Re: [SOLVED] Program is there, but bash can't find it

#25 2015-02-03 21:00:55

Re: [SOLVED] Program is there, but bash can't find it

Board footer