Linux: controlling where `ld` searches for .o object files?

Ok, this is the situation: I'm trying to use some older software: works fine on Ubuntu Lucid, fails on Natty.

So, I straced around a bit, and it turns out that this software calls ld, and ld eventually fails with:

.../ld: crt1.o: No such file: No such file or directory

... yes, the old crti.o file missing error :) However, I'd like to ask the question in more general terms...

The thing is, this is '开发者_Python百科standalone' (older) ld here, and when I run .../ld -verbose | less, I get:

...
SEARCH_DIR("/usr/local/lib"); 
SEARCH_DIR("/lib"); 
SEARCH_DIR("/usr/lib");
...

Now, the thing is that:

• On Lucid, crt1.o is in /usr/lib/crt1.o
• On Natty, crt1.o is in /usr/lib/i386-linux-gnu/crt1.o

... so no surprise why crt1.o cannot be found, I guess. It seems, all I have to do, is tell ld to look for crt1.o in /usr/lib/i386-linux-gnu, but how do I do that?

I thought I could use the -L option, but man ld says:

to link a file "hello.o":

    ld -o <output> /lib/crt0.o hello.o -lc

  This tells ld to produce a file called output as the result of linking
  the file "/lib/crt0.o" with "hello.o" and the library "libc.a", which
  will come from the standard search directories. 
...

-L searchdir
--library-path=searchdir
  Add path searchdir to the list of paths that ld will search for
  archive libraries and ld control scripts.

... meaning, '-L' would influence where we look for "libc.a" (in man example) - but not for the object files.

I would actually prefer an environment variable for this, but I tried both LD_PRELOAD_PATH and LD_LIBRARY_PATH to no avail (I guess, those are related to "shared objects", and these .o files aren't one of those).

Does anyone know if there is an environment variable (preferably - or if not, command line option to ld) that would control where ld searches for .o object files?

As a note, I guess I could just symlink /usr/lib/i386-linux-gnu/crt1.o in /usr/lib/, but I'd rather use an environment variable, if it exists... If not, are there any other possible solutions to this?

Thank in advance for any answers,

Cheers!

EDIT: possibly relevant: Daniel Kegel - --with-sysroot newbie troubles: "ld: cannot open crt1.o"

OK, after some messing about, I think I managed to solve my original problem (though note, as far as the original question goes, it's still the same answer as the accepted answer):

LIBRARY_PATH=/lib/i386-linux-gnu:/usr/lib/i386-linux-gnu:$LIBRARY_PATH myprogram --args..

Here is the distinction which I should remember:

• LD_LIBRARY_PATH is used to 'help' an executable find library files, when it is run (i.e. loading, LD_)
• LIBRARY_PATH helps gcc, g++ and company find libraries referenced via '-l' argument (for instance, -ldl, i.e. libdl, which was also a problem in my case; see man g++ for more on LIBRARY_PATH)

So since myprogram was calling g++, ld and such, and those were crashing unable to find the libraries during compilation - adding the LIBRARY_PATH argument seems to have fixed the g++/ld behavior, and so I don't get problems (even with crt1.o!) anymore with myprogram.. Hopefully that will last :)

Thanks all for the help,
Cheers!

ld doesn't use a search path for .o files at all - you must pass it the full path (as in the example you quote from the manual). So no, there is no way to change the search path it uses to find .o files.

In general, ld shouldn't be called directly - for instance you'd normally call gcc instead to do your linking. I'd say it's the program calling ld which is at fault here.

You can use also --sysroot:

   --sysroot=dir
       Use dir as the logical root directory for headers and libraries.  For example, if the compiler normally searches for headers in /usr/include and libraries in /usr/lib, it instead searches
       dir/usr/include and dir/usr/lib.

       If you use both this option and the -isysroot option, then the --sysroot option applies to libraries, but the -isysroot option applies to header files.

       The GNU linker (beginning with version 2.16) has the necessary support for this option.  If your linker does not support this option, the header file aspect of --sysroot still works, but the
       library aspect does not.

!!! => The GNU linker (beginning with version 2.16) has the necessary support for this option.

if that's and x86_64 machine (I think it is) then you should make sure you have libc6-dev installed (i think the other crt1.o is libc6-dev-i386's file IF natty is renaming the 32bit libs folders (on previous releases its /usr/lib32) ....

if you're compiling for 32bit and you get that error... that must be a bug in gcc/g++; try giving it the path with the -B option