Linux executable headers
category: code [glöplog]
...OK, so as I understand it, an executable program header has references to shared object files whose code it calls, inside the exe, and the system searches for these from the PATH env variable.
My question is - why? Why not just put the FULL path to the .so file inside the header like /usr/lib/mylib.so.1 or whatever?
I probably have no idea what I'm talking about :) , and I realise it's offtopic here, just thought someone here might know... :)
(Btw, I'm talking about a 64 bit system, if that's necessary....)
My question is - why? Why not just put the FULL path to the .so file inside the header like /usr/lib/mylib.so.1 or whatever?
I probably have no idea what I'm talking about :) , and I realise it's offtopic here, just thought someone here might know... :)
(Btw, I'm talking about a 64 bit system, if that's necessary....)
If it did that you'd never be able to relocate the library to accommodate other things or have multiple versions on the same system.
Actually it searches in the LD_LIBRARY_PATH and there is a cache populated by "ldconfig".
It allows for some tricks, like using a different version of a lib to run a particular executable (like in Windows, where it looks for DLLs first in the current dir, then in C:\windows\system).
This makes the executables slightly smaller (no need to store full paths, just sonames), is more flexible, and with the ldconfig cache, possibly faster. By the way, note that the name stored in the ELF header needs not match the name of the library, there can be aliases, a "soname" inside the .so ELF file headers, and some more magic. Basically, ldconfig builds a map of all this so a name can be quickly matched to the relevant file, without searching the filesystem.
It allows for some tricks, like using a different version of a lib to run a particular executable (like in Windows, where it looks for DLLs first in the current dir, then in C:\windows\system).
This makes the executables slightly smaller (no need to store full paths, just sonames), is more flexible, and with the ldconfig cache, possibly faster. By the way, note that the name stored in the ELF header needs not match the name of the library, there can be aliases, a "soname" inside the .so ELF file headers, and some more magic. Basically, ldconfig builds a map of all this so a name can be quickly matched to the relevant file, without searching the filesystem.
Quote:
By the way, note that the name stored in the ELF header needs not match the name of the library, there can be aliases, a "soname"
This is a trick. It should be the exact name of a shared library and not a hard/soft link name.
iirc the standard defines libNAME.so as a valid name for linker (in order to make the search quicker) and libNAME.so.MAJOR.MINOR as a valid name for the loader.
But it doesnt really matter, technically it will work as well.
Thanks guys! :)
Actually, this came up cuz I was recently trying out booting Linux from a USB stick and running from there - what I wanted to know was, can I just install stuff from like, "Software Centre" or apt-get or dnf or whatever without a problem? Like, it won't matter if I don't have a HD/SSD?
But I saw that Bodhi Linux, for whatever reason, locks "/" for writing (though I'm not sure I got this right), so what I wanted to do was have one USB stick for the OS, and download whatever software onto *ANOTHER* USB, and just have it run if I insert that stick and click on it (I'd put each package inside it's own directory, obviously). Is this possible?
I have a feeling that that's not what I asked up there, though :) I'm so thoroughly confuzzled :)
But I saw that Bodhi Linux, for whatever reason, locks "/" for writing (though I'm not sure I got this right), so what I wanted to do was have one USB stick for the OS, and download whatever software onto *ANOTHER* USB, and just have it run if I insert that stick and click on it (I'd put each package inside it's own directory, obviously). Is this possible?
I have a feeling that that's not what I asked up there, though :) I'm so thoroughly confuzzled :)