Printable View
Hello all!
I am writing a program in x86 asm, using nasm syntax, and using opengl and sdl. I assemble my program with:
nasm -f elf main.asm
and link with:
ld -o main main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so
so far so good. It produces an executable with no issues. However, when I try to run it with
./main
It says "No such file or directory"
What is going on here? When I do ls, main shows up.
Thanks!!
> It produces an executable with no issues.
It may have produced a file, but how do you know it's executable?
If you do 'ls -l', does the file have the 'x' permission bits set?
Can you post the actual terminal session. Perhaps there is a typo in what you typed which is not reflected in your post.
Here is the session:
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ ls
main.asm main.asm~ makefile makefile~
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ make
nasm -f elf main.asm
ld -o main main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ ./main
bash: ./main: No such file or directory
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ ls -l
total 24
-rwxr-xr-x 1 kerry kerry 3009 2007-09-02 02:42 main
-rw-r--r-- 1 kerry kerry 1585 2007-09-02 02:42 main.asm
-rw-r--r-- 1 kerry kerry 1581 2007-09-02 02:05 main.asm~
-rw-r--r-- 1 kerry kerry 1760 2007-09-02 02:42 main.o
-rw-r--r-- 1 kerry kerry 364 2007-09-02 02:41 makefile
-rw-r--r-- 1 kerry kerry 364 2007-09-02 01:45 makefile~
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$
I think it's some weird bug with ld, but maybe I am not linking right? It just doesn't make sense. ls can find the file, but bash can't.
Thanks!
Can you do 'ls -lb' in case make is generating a file which only looks like 'main', but in fact contains invisible characters. The -b option will show these up. If this is the case, then you need to carefully inspect your makefile using an editor which will reveal such invisible characters.
Also, try typing './m' then pressing the tab key to cause bash to attempt it's own filename completion. If it comes back with something looking like './main', then press enter and see if that runs the program.
ls -lb gives the same result as ls -l
and ./m tab causes it to auto complete with ./main (but still giving me the same error when i run it!)
thanks!
Have you tried giving the file a different name? I don't think "main" is some sort of reserved name, but worth a try.
It may be that it's something else going wrong (and the error message is a bit misleading). Try "strace ./main" - post the part towards the end if you're not familiar with "strace" output (the last several lines will have to do with printing the "file not found" error message - that's not the really interesting bit, but what happens before that for several lines would be).
Also, if there's a space or some such at the end of the name, such as "main ", then it would stop at "main" when auto-expanding, because it's ambiguous between "main ", "main.c" and "main.o" for example.
--
Mats
The file definitely exists, I have tried changing the name and everything. Here is the output from strace:
I really think that it has something to do with how i am linking, but I am not sure why that would give me a "no such file or directory" error.Code:kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ strace ./main
execve("./main", ["./main"], [/* 31 vars */]) = -1 ENOENT (No such file or directory)
dup(2) = 3
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fstat64(3, {st_mode=S_IFCHR|0620, st_rdev=makedev(136, 2), ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb7f13000
_llseek(3, 0, 0xbf910a04, SEEK_CUR) = -1 ESPIPE (Illegal seek)
write(3, "strace: exec: No such file or di"..., 40strace: exec: No such file or directory
) = 40
close(3) = 0
munmap(0xb7f13000, 4096) = 0
exit_group(1) = ?
Process 13595 detached
Thanks!
But your strace clearly shows that the OS doesn't think your file exists!!
The thought I had was that it was somehow a shared library or some such that didn't exist.
Try this: "mv main blah" - if that shows the file doesn't exist, then it's certainly something up with the filename.
--
Mats
mv works. every file manipulation tool, such as ls, mv, cp, works fine on it. is this a bug with linux??
I doubt it's a bug in Linux - Linux may well have bugs, but something as trivial as this shouldn't happen in your kernel.Quote:
Originally Posted by kerryhall
It seems from strace that it's simply not finding the "main" file - which means to me that it's "not there" in the filesystem in general. Unless of course some security scheme is saying "don't let this user run anything" - quite often, the error codes from such security schemes are "obfuscated" to hide that it's the security system saying you can't do this - instead of saying "You are not allowed to do this", it says "the file doesn't exist", that way you don't KNOW that it's the security system that is causing the problem.
So does the new file (blah or whatever) work to run? If you copy, say, grep to main, does it work then?, using "cp /usr/bin/grep main" (or similar). Can you build a simple hello program?
Anoter option is that the file is refused to load (and the kernel doesn't distinguish on a fine-grain enough) because there's something else wrong with your load process. Could you dump with "objdump -d" the first few lines of assembler, and compare that to for example a C program (grep will work) to see if there's some noticable difference - if you are not sure, post some 10-15 lines of each here and I should be able to do that.
--
Mats
--
Mats
In addition, do programs created with say gcc run as expected?
Hey Kerryhall, what does the output of "ldd ./main" say?
Programs on Linux can give a "No such file or directory" when they aren't dynamically linked quite right.
programs created with gcc work fine.
Am I linking right?
my assembling and linking commands:
there doesn't seem to be anything significant with objdumpCode:nasm -f elf main.asm
ld -s -o main main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so
and here is the result of ldd
thanks all!!Code:kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ ldd main
/usr/bin/ldd: line 117: ./main: No such file or directory
The file's there, it's executable, objdump thinks it's okay, but ldd borks too. Well, ldd works by setting some magic environment variables and then running the binary, so that would be expected.
This is just a wild guess, but can you run ANY program called ./main? Try copying /bin/ls to ./main and see if that will run.
Yes, I can run any program called main.
Given that programs created with gcc work fine, then I would say that there is something wrong with your ld command line.
Try
This too will just call ld, but it will use the compiler driver to make sure that all the correct options are passed to ld. The purpose of the -v option is so that you can see what all those options are.Code:gcc -v -s -o main main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so
Sorry in advance for the extra wide post!
Code:kerry@BigOwl:~/Programming/x86_asm/extern_func_03$ gcc -v -s -o main main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr \
--enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix \
--enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug \
--enable-mpfr --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.1.2 20060928 (prerelease) (Ubuntu 4.1.1-13ubuntu5)
/usr/lib/gcc/i486-linux-gnu/4.1.2/collect2 --eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 \
-o main -s /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crt1.o /usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crti.o \
/usr/lib/gcc/i486-linux-gnu/4.1.2/crtbegin.o -L/usr/lib/gcc/i486-linux-gnu/4.1.2 \
-L/usr/lib/gcc/i486-linux-gnu/4.1.2 -L/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib -L/lib/../lib \
-L/usr/lib/../lib main.o /usr/lib/libGL.so /usr/lib/libGLU.so /usr/lib/libSDL.so -lgcc --as-needed -lgcc_s \
--no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i486-linux-gnu/4.1.2/crtend.o \
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../../../lib/crtn.o
kerry@BigOwl:~/Programming/x86_asm/extern_func_03$
So I think there should be something else that I should link to, but I'm not sure what.
Also, if there is something that I don't link to, why do i get a "no such file or directory" error?
Thanks!!
I didn't see a post of objdump output - the first few lines would be a good start.
Does the file linked with gcc work?
--
Mats
Well it seems to link, did the result run, or did it also result in "no such file or directory" ?
Well, this problem is baffling me and I really want to help you solve it. Is this code particularly sensitive, or could you gzip the binary and put it on the web somewhere? I'd like to sift through it with objdump and try a few other tricks.Quote:
Originally Posted by kerryhall
Going through the whole process on a message board just takes too long.
Thanks to everyone for your help! :)
The version linked with gcc runs.
The version linked with ld produces the error.
I must be making an error with the linking, but I can not understand why that produces such a weird error.
The code is not sensitive, I can zip it and attach it. I am reluctant to do so, however, since I am learning asm right now, the code probably has tons of errors, its a bit embarrassing.
If someone could just tell me what parameters to pass to ld, then I think I would be set. (However, it doesn't answer the question of why an improperly linked file produces a "no such file or directory error")
Thanks!!
Look at the final command line generated from invoking the linker via gcc.
Strip out all the -L and -l options, which are just directives for searching libraries (you've got that covered already).
Since you're linking with shared objects, then these seem likely candidates to add to your command line
-dynamic-linker /lib/ld-linux.so.2
These may be needed, but check with the ld manual page to find out what they do.
--eh-frame-hdr -m elf_i386
I don't think you should feel particularly weird from using gcc to invoke the linker rather than doing it yourself. If you get to the point of distributing source, then your direct invocation of ld on other systems may well show other equally obscure problems. Whereas using gcc to make sure all the correct options are passed would be expected to work on all systems.
--eh-frame-hdr is for exception handling. It's probably not needed in hand-coded assembly.
-m elf_i386 is just making explicit the default setting of the linker: to generate ELF executables for the i386 (IA-32) architecture. Although ... if the default settings of the linker are screwed up, perhaps it's this that makes it work.
Thanks to everyone for their help!
ld -dynamic-linker /lib/ld-linux.so.2 -o main main.o /usr/lib/libSDL.so /usr/lib/libGL.so /usr/lib/libGLU.so
produces a executable that runs!
So I guess I needed "-dynamic-linker /lib/ld-linux.so.2" but does anyone know why not linking to that produces a "no such file or directory error" ?
This is very bizarre. Are there any other link-loaders to be found in /lib? Try:Quote:
Originally Posted by kerryhall
I don't think we're done here yet ;) "ld" should be choosing the appropriate link-loader without the need for -dynamic-linker.Code:ls -la /lib/ld-linux*