Ricardo Wurmus <rek...@elephly.net> skribis: > Andy wrote: > >> It would be pretty cool if we could fix our O(n^2) problems in search >> paths in this core-updates -- basically whenever you go to create an >> environment, instead of making e.g. VAR=A:B:C:..., for all VARs >> (LIBRARY_PATH, PKG_CONFIG_PATH, etc), instead we make a union directory >> Z containing the union of A, B, C, etc and set VAR=Z. The goal would be >> to fix quadratic run-time lookup costs by replacing it with a >> compile-time computation. This applies to many lookups: PATH, -rpath, >> etc. > > Ludo wrote: > >> A possible alternative solution for ld.so is at >> <https://bugs.gnu.org/26048>. > > Do you know of any negative side effects this would have? For example, > would it not become impossible to override libraries at runtime with > LD_LIBRARY_PATH or LD_PRELOAD when “-lfoo” is replaced by the absolute > file name of the “foo” library?
Good question. Per the ELF v1.2 spec¹ (page 82), setting DT_NEEDED to an absolute file name would prevent overriding via LD_LIBRARY_PATH, which is not desirable. It turns out we cannot even set DT_NEEDED to an absolute file name in the first place, because ld records the DT_SONAME of the library, when it’s available (which is the case most of the time), rather than its file name. IOW, the approach suggested in <https://bugs.gnu.org/26048> isn’t really applicable. :-/ Ludo’. ¹ http://refspecs.linuxbase.org/elf/elf.pdf