0

This is a question about centrally-located path specs, like PATH, LD_LIBRARY_PATH, and LIBRARY_PATH.

I know that there are two ways of specifying shared library paths for the loader: add them to LD_LIBRARY_PATH, or add files to /etc/ld.so.conf.d/. I also know that the latter is considered the more modern and preferred way to do it.

I also know that you can specify standard library paths for the linker by editing LIBRARY_PATH. Is this still the "modern" way to do it, or is there now a "ld.so.conf.d-style" alternative that I should be using?

EDIT: People are asking "why", so:

I'm using a Python package (Theano) that dynamically generates and compiles CUDA and C++ code when run. One of the libraries it links to is NVidia's cuDNN. I don't know why Theano's developer's have it link to the static lib and not the dynamic lib.

SuperElectric
  • 17,548
  • 10
  • 52
  • 69
  • Please explain why do you ask. With statically linked binaries, your question has no real sense. But you should prefer dynamically linked binaries. What are the executables whose static libraries you want to change at runtime? – Basile Starynkevitch Mar 19 '15 at 19:49
  • Are you looking for a mechanism that the linker will pay attention to (at link time, not run time) when determining where to find static libraries? – Keith Thompson Mar 19 '15 at 19:50

2 Answers2

2

There isn't any equivalent to ld.so.conf.d/ for static libraries. You still just specify the standard linker search paths via the LIBRARY_PATH environment variable, and additional paths through command-line flags to the linker.

To be clear:

  • LIBRARY_PATH: Used by the linker at compile time. Is used by the linker to find both static and dynamic libraries.
  • LD_LIBRARY_PATH: Used by the loader at run time to find dynamic libraries.
SuperElectric
  • 17,548
  • 10
  • 52
  • 69
kaylum
  • 13,833
  • 2
  • 22
  • 31
  • There's no need for a standard search path for the linker, and yet there seems to be one (LIBRARY_PATH), for convenience. I was just wondering if tweaking LIBRARY_PATH was still the most modern way to go about it. – SuperElectric Mar 19 '15 at 22:03
  • Ok, you confused us/me somewhat with the wording of the question because ld.so.conf and LD_LIBRARY_PATH are runtime. Whereas you really mean link time. And yes, LIBRARY_PATH is the way to do it if for some reason you want to override or extend the default standard library paths. For one-time or application specific builds you would generally just use the "-L" option in the Makefiles. – kaylum Mar 19 '15 at 22:11
  • It seems like LD_LIBRARY_PATH and LIBRARY_PATH serve the same purpose, one for dynamic loading of shared libraries and the latter for static linkers. So why would it necessarily not "make sense" for there to be an analogue to ld.so.conf.d/ for static linking? If you edit the answer to address this, I'd select it. – SuperElectric Mar 20 '15 at 02:00
  • 1
    Answer updated. Specifically, LIBRARY_PATH applies to both static and dynamic libraries at compile time. LD_LIBRARY_PATH is relevant only for dynamic libraries at run time. There is no concept of or need for a search path for static libraries at run time. – kaylum Mar 20 '15 at 02:40
  • I of course understand that there's no concept of or need for a search path for static libraries at run time. Most do. There's also no mention of such a concept in the question; you hallucinated it after seeing LD_LIBRARY_PATH being mentioned. I mentioned that because the question is about centrally-located path specs, like LIBRARY_PATH, and PATH. I'll edit the question, and your answer, to re-emphasize this focus. – SuperElectric Mar 20 '15 at 12:48
0

static libraries are resolved at (static) link time and by definition don't have any runtime aspects.

My opinion is that you should avoid using static libraries and always prefer shared libraries.

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547