[ note: list lag is still days: see http://savannah.gnu.org/forum/forum.php?forum_id=4322 ]
* Pierre Ossman wrote on Wed, Mar 01, 2006 at 10:00:43AM CET: > Ralf Wildenhues wrote: > > > >In theory: no run paths for paths that the runtime linker searches by > >default. Otherwise, rpaths for all libraries we link directly against. > >(Omitting the minor detail that we care about the difference of > >uninstalled vs. installed locations, for simplicity.) > > If I read the above threads correctly there are some problems > determining the runtime paths automatically (mainly because gcc doesn't > give the complete picture). Yes, more or less. We also have a similar issue on Solaris/64 ATM, but that should be fixable by looking at $host and $LD (as we compute it). > In this case, user assistance is acceptable, > so would adding a -R to the libtool invocation make it stop adding rpaths? No. Au contraire: -R is the flag to add more run paths, not to remove them. > Is there perhaps also some environment variable that can be used to pass > this information? That would allow "make RPATHENV=/usr/lib64" and I > wouldn't have to mess with the build system. Not at the moment. You could change the setting of sys_lib_dlsearch_path_spec in the generated libtool script (once for each tag). An patch implementing a functionality like the one you desire would be useful. I'm just not sure about exact semantics and syntax: - a `libtool --mode=link' option, or - an environment variable, or - a configure option Note there's also been the suggestion to allow a specific environment variable to contain all kinds of libtool options; or one for each mode. Next question: should it be possible to - add paths to this list, or - remove paths, or - just set the path list to something new? Should the paths be normalized or not? Which setting should override which? If we can agree on something sane here, I'm all for moving forward an implementing it. In practice, some distributions have added patches to their installed libtool.m4 to adjust sys_lib_dlsearch_path_spec and sys_lib_search_path_spec to their way of doing it. Good for their packages, but makes for interesting failures when you then take a tarball created there to another distribution. Cheers, Ralf _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
