XPost: uk.comp.os.linux   
   From: invalid@invalid.invalid   
      
   Theo  writes:   
   > Java Jive  wrote:   
   >> [USER@NASNAME ~]# gcc --version   
   >> -sh: /share/CACHEDEV1_DATA/.qpkg/Entware/bin/gcc: No such file or directory   
   >>   
   >> [USER@NASNAME ~]# make --version   
   >> -sh: /share/CACHEDEV1_DATA/.qpkg/Entware/bin/make: No such file or directory   
   >>   
   >> Note that the directory listing and the uname output show that the   
   >> hardware objective coding of the development utilities is correct for   
   >> the hardware, and I can't think of any other reason why the utilities   
   >> won't run.  Any ideas anyone?   
   >   
   > As Richard says, 'no such file or directory' when running a binary   
   > usually means either the binary format is not supported (eg trying to   
   > run Arm binaries on x86),   
      
   Wrong architecture yields ‘exec format error’ for me.   
      
       $ ./ls   
       -bash: ./ls: cannot execute binary file: Exec format error   
      
   > or some shared library is missing which means the dynamic linker is   
   > not able to start the program.   
      
   Shared libraries produce a friendlier diagnostic, listing the missing   
   shared library for me:   
      
       ./t: error while loading shared libraries: libl.so: cannot open shared   
   object file: No such file or directory   
      
      
   The cause of bare ‘No such file or directory’, without further   
   explanation, is either when the file directly addressed actually doesn’t   
   exist, or when there is no better reporting channel to indicate what is   
   missing. We know the file does exist so we’re in the second of these   
   possibilities.   
      
   The usual cause is where the ‘interpreter’ is absent; for scripts the   
   interpreter is the token after the #!, for dynamic executables it’s the   
   runtime linker. Either way the only error channel is the errno value set   
   by the execve() syscall.   
      
   I can’t 100% rule out other possibilities, but the answer in this case   
   is almost certainly a missing runtime linker, which was my first   
   suggestion. The failure of ldd mention in another post supports this,   
   given the rather bizarre way ldd works.   
      
      
   Concrete suggestions:   
      
   1) Review the origin of these executables. Perhaps there is some   
      information about their dependencies there. I already suggested this   
      but there doesn’t seem to have been any followup.   
      
   2) Run   
        file /share/CACHEDEV1_DATA/.qpkg/Entware/bin/gcc   
      to find out what kind of executable they are.   
      
   --   
   https://www.greenend.org.uk/rjk/   
      
   --- SoupGate-DOS v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)