|I have the file libbfd-2.26.1-system.so in the right place and with the proper symbolic link.|
I am bootstrapping a gcc compiler and it compiles fine so far, but does not link. When I do this, I simply create a directory, then I expand all the binaries from about 30 or so packages and I proceed to test the compiler and linker and runtimes made from them. So I am still setting things up but I wanted to test the linker so I am running the command strace -v to do that.
/usr/lib/x86_64-linux-gnu is a typical place for libbfd-2.26.1-system.so to reside. On all of my linux distros that I'm concerned with, the file is in that directory.
If I run strace on a machine that does NOT have any problems with ld, I would get an strace -v that looks something like this in the beginning:
CORRECT ld, or at least good enough to link, let's say:
execve("/usr/bin/ld", .......) = 0
open("/usr/lib/x86_64-linux-gnu/libbfd-2.26.1-system.so ...) = 3
I am being brief and cryptic above just to illustrate the basic flow.
The difference in the case of the one that does not work is that the path to the open command is incorrect - I just don't know why - is it package-related?
If you need more detail, I'll have to put together a more detailed analysis. But I'm wondering, is it cache-related and if so, should I clear my caches out or should I find the incorrect entry and edit them? I realize I might be completely in the dark - it might have little to do with the caches. So I have two compilers - an old one and a more recent one that I am bootstrapping with binary installs of all the packages.
The tls reference has something to do with threading - so perhaps I need to turn something on or off?
I know that the structure of my ld.so.conf script might have a lot to do with it. So I will play with this this evening. My gnu machine has a slightly different way of dealing with .conf than typical ubuntu distros so I need to get this configged better.