Given that programs created with gcc work fine, then I would say that there is something wrong with your ld command line.
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.
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!
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.
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 \
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?
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?
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.
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")
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
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:
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.
ls -la /lib/ld-linux*