4

If I run the command foo specifying a a different libc to use as follows:

LD_LIBRARY_PATH=$PATH_TO_MY_CUSTOM_LIBC foo

Is the globally defined libc used to run any of the command given above?

For the sake of context: consider the situation where your libc is physically present and accessible on your machine, but cannot be used for some reason. Given a logged in shell, in order to execute a specific command, you would need to provide a different libc.

Specifying the LD_LIBRARY_PATH inline, would set it to the location of a working libc without apparent need to call the globally defined one.

Would the globally defined libc be called all the same in order to define locally the new environment variable?

eyoung100
  • 5,717
  • 21
  • 50
user213575
  • 43
  • 1
  • 4
  • Your problem seems a bit like a job for LD_PRELOAD. – Tomasz Myrta Sep 02 '15 at 18:49
  • I cannot get your point but just `LD_LIBRARY_PATH=$PATH_TO_MY_CUSTOM_LIBC foo` doesn't work for you? – yaegashi Sep 02 '15 at 18:49
  • @TomaszMyrta `LD_PRELOAD` is to load a library before every other library, so you can write an own function which is normally provided by libc, for example; You can hook them. – chaos Sep 02 '15 at 18:55
  • @yaegashi I entered the bash -c because the foo command originally contained a pipe, but for the sake of the question is indeed not useful – user213575 Sep 02 '15 at 19:02

2 Answers2

2

No. Dynamic linking isn't part of the libc in the sense of /lib/libc.so.6, it is the functionality of the /lib/ld.so (both of them got a little bit changed file name and path in the last years, but the essence is the same).

Yes, ld.so, the dynamic linker is a shared library as well. Loading it is the first thing what most linux binary does, yet before calling its main() function.

Although ld.so is a different file of the libc, it is also part of the gnu libc distribution in both of its source and compiled binary forms.

Linking in the ld.so is going from a hardcoded code chunk, given by the gcc to every linux ELF binary. Its path is also hardcoded into the binary. You can't change that easily, although it is possible if it is needed.

If you override libc.so.6 with an alternate LD_LIBRARY_PATH setting, this library will supersede the orderntly libc with your own, but it will be still loaded by the normal ld.so.

Thus the answer to your question is "yes, but...".

peterh
  • 9,488
  • 16
  • 59
  • 88
  • Just today I found a problem, where the simplest solution was that I binary edited the ld.so path in the precompiled binary. (I had to install a Debian tool into a Suse system while I didn't get root permission). – peterh Sep 03 '15 at 14:34
1

When you execute the command given in the question:

LD_LIBRARY_PATH=$PATH_TO_MY_CUSTOM_LIBC bash -c 'foo'
  • The executed bash uses the libc provided in the path $PATH_TO_MY_CUSTOM_LIBC if there is one there. It's the linker/loader which honours that environment variable.
  • The command that is executes inside that bash (you called it foo) will use the libc that can be found regularly your the system by the linker/loader which itself consults /etc/ld.so.cache.
chaos
  • 47,463
  • 11
  • 118
  • 144
  • I edited my question because I had added the bash -c before the execution of the command by mistake – user213575 Sep 02 '15 at 19:06
  • @user213575 Ok, but that doesn't matter, the answer is anyway: No the one defined in the `LD_LIBRARY_PATH` would be used for that binary. – chaos Sep 02 '15 at 19:10