2

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?

|improve this question
  • Your problem seems a bit like a job for LD_PRELOAD. – Tomasz Myrta Sep 2 '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 2 '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 2 '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 2 '15 at 19:02
1

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...".

|improve this answer
  • 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 3 '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.
|improve this answer
  • I edited my question because I had added the bash -c before the execution of the command by mistake – user213575 Sep 2 '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 2 '15 at 19:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.