|Subject:||Flag for propagating -R?|
|Date:||Mon, 6 Dec 2010 16:14:52 -0800|
This has come up a couple times before. This time I have an actual proposal. Right now, libtool does NOT propagate -R (runtime path) in dependency_libs, even though the documentation says it does, here:
This is so that executables linked with libtools (e.g. in a distribution) do not inadvertently suck in external library dependencies, or at least that's the rationalization that you've explained in the past. Things have been like this for at least a couple years now.
For some projects, especially in environments with a lot of packages in different directories, it's useful to have the -R propagated, so that users don't have to set a million things in their LD_LIBRARY_PATH. Could we have a command line flag to libtool that enables this behavior? It's a really simple fix:
-R propagation is nixed right here in the libtool script:
That is around line 7567. That makes -R pretty useless, because you don't pick up the -R's for *all* dependency libs when linking executables.
All you have to do to propagate -R's through all of a program's dependencies is this:
Could you add a flag to libtool or a parameter to LT_INIT to do this conditionally? It would be nice if you could supply an argument to configure, similar to --enable-shared or --disable-shared that controls this behavior.
I'm not sure what the best place to put the switch would be, but I'd really like to have this capability so that users can build projects and not worry about things like LD_LIBRARY_PATH for dependencies that may be all over the filesystem.
Is this doable? Currently there's no way to get the above behavior, short of having my build run sed on libtool. I'd be happy to try to contribute something like this, but you know better than me who will be affected by the change, so I'd like your opinion.
|[Prev in Thread]||Current Thread||[Next in Thread]|