Cannot run an executable in current directory even using ./
 

Hi all,

Having downloaded an Astronomy program from the Internet, unTARed the content and run the install script, I now apparently have all executables and files in place where they should be.

However, if I then navigate to the directory holding the executable and ls -l, I can see it listed showing that it can be executed by all. If I then type the executable name (xplns), I get a directory/file does not exist type message. If I type ./xplns I still get the same error !

Can anyone explain to me what I am doing wrong ? I am running SuSE Linux 7.3.

Regards,

Ian.

If you're sure you're in the same directory and the permissions are set correctly on the file (+x set for your user at least), a
should give you at least a message (why?) the file cannot be executed. Make sure you type it correctly (uppercase letters differ from lowercase!)

After this make sure the directory you're in is made executable, it might affect..

What exactly do you get with
and
?

Hi b0uncer,

I've checked that the file is executable uning ls -l, and thats OK, I've double-checked that the file name typed in is in the same case as the file listed.

However I have not checked to see if the directory itself is executable. I'll ls -ld ./ and see what is returned.

Thanks for the suggestions !

Ian.

Check that it is compiled for your architecture. I've seen zsh throw up file not found errors when in reality it can't execute the binary.

Wow I hope you've made sure the zsh creators know that? Sounds almost too Windows to me - error messages that are not telling anything about the actual problem..

Is the executable located in a filesystem that is mounted with noexec option? (/etc/fstab)

I have now checked the directory holding the executable, and all directories above up to root level. All have permissions as follows : drwxr-xr-x

The xplns executable has permissions as follows : -rwxr-xr-x

So I cannot see any write permission problems there.

I then ran file xplns which gave the following output :

xplns:ELF 32-Bit Binary LSB Executable Intel 80386 Dynamically linked (uses shared libs), stripped

I had another look at the vendors FAQ page regarding the product installation. The ELF executable was apparently created for Slackware 3.x Linux, (tar.gz files) so maybe I downloaded and installed the wrong set of files. Alernative downloadables are as follows :

Red Hat (glibc 2.1/2.2/2.3 - .rpm files) or FreeBSD (FreeBSD i386 ELF - .tgz files)

I then read that SuSE 7.3 uses glibc 2.2. The vendor recommends checking which glibc version to download by issuing command ls /lib/libc-* however, this resulted in no matching files. So now I am not sure whether SuSE uses glibc or not.

I didn't know that program install packages were so distribution dependant. :scratch:

Should I remove the current installation and try the glibc 2.2 version anyway, or is there another way of confirming which sets of files I should download ?

Regards,

Ian.

Appears to me there are plenty of binaries available for that program. Is there a reason you have to install from source?

Hi Rickh,

I thought I was using binaries ... I downloaded the software plus zipped star catalogue files from the vendors website below.

http://www.astroarts.com/products/xplns/download.html

Most other sites I have found via Google by searching on xplns, point back to this download site, again giving you the choice of glib2.1, glib2.2, glib2.3 or libc5.

Could you point me to some of the locations of binaries you mention ?

Regards,

Ian.

Hi all,

Problem solved ! :)

Having mamaged to confirm SuSE 7.3 uses the glibc2.2 (soname - libc.so.6) libraries, I uninstalled the existing version of xplns (libc5), and downloaded and installed the glibc2.2 rpm files.

Now upon typing just xplns at the console, the application starts up fine and works flawlessly.

So, cs-cam, your suspicions were confirmed, i.e. the file not found error was just reflecting the wrong version for my linux installation.

Many thanks for all the contributions !

Ian.

It has nothing to do with zsh, that is the error message is returned by the kernel (often because some shared lib can't be found, as seems to have been the case here).

You can confirm this easily; copy, say, /bin/bash to /tmp/foo/bash, then (as root) cd /tmp/foo and strace chroot . ./bash. I get:

P.S. In these situations, the first tools I'd use are ldd and strace. For most simple cases, these will show what the problem is.