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
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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!!
Last edited by Salem; 09-04-2007 at 02:38 AM. Reason: wrapped for clarity
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" ?
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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")
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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
--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.
All the buzzt!
CornedBee
"There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
- Flon's Law
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:
I don't think we're done here yetCode:ls -la /lib/ld-linux*"ld" should be choosing the appropriate link-loader without the need for -dynamic-linker.
