On 2017-06-01 18:46:56 +0200, Thomas Jahns wrote: > On 06/01/2017 11:09 AM, Vincent Lefevre wrote: > > Perhaps defining the LD_RUN_PATH environment variable instead of > > LD_LIBRARY_PATH could be a workaround, but gold does not support > > it, so that this cannot be a general solution. > > Linking is very platform- and tool-dependant. LD_LIBRARY_PATH is also not > general (read what it does on BSD or Solaris to find out more, it does not > do anything on e.g. AIX, macOS, Windows...).
MacOS has something equivalent (DYLD_LIBRARY_PATH). > > Moreover, what path should be given when the library is on NFS, where > > the mount point (e.g. $HOME directory) depends on the machine? > > That's just an accident waiting to happen and shows more about bad system > management than tooling. But as I wrote, library paths that are invariant > relative to the binary can still work. This is not the case in general: libraries are installed by the user in $HOME/lib, but binaries can be anywhere under the $HOME directory. > > > will do just what's needed (for most people on this list libtool > > > does so for them). > > > > libtool is used to compile libraries, but in general, the user does > > not use it to build an executable. > > On the contrary, in autotools projects, libtool is automatically used for > linking both, libraries and executables. First, autotools projects are not always used. If a user writes a small C program that uses some library installed in $HOME/lib, he will just invoke the compiler (a Makefile isn't even necessary in simple cases). Second, even if libtool is used, how does it know where to search the library? -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon) _______________________________________________ https://lists.gnu.org/mailman/listinfo/libtool
