Sorry for reviving a slightly old thread... * Paul Eggert wrote on Mon, Jul 17, 2006 at 11:41:13PM CEST: > Patrick Welche <[EMAIL PROTECTED]> writes: > > > so the -R made it, and all is well :-) > > > > I can't check the opposite though: do systems that don't want rpath get > > one now? > > Yes, they probably do. Perhaps the libtool guys can chime in on > whether the patch was a good idea.
No, I don't think that was such a good idea. The most prominent reason being the one mentioned by Russ: * Russ Allbery wrote on Fri, Jul 21, 2006 at 04:03:27AM CEST: > > Adding -R for system X libraries is always the wrong thing to do on Debian > systems and will break multiarch builds. I really don't think this is the > right solution. None of the current GNU/Linux distribution like to add run paths to the system libraries or programs, as this makes it harder to build relocatable packages and whatnot else. Also, I know no other recent unix that commonly puts run paths for /usr/lib*, /usr/X11R6/lib* or similar into their system programs (the `*' indicating some optional ABI suffix). So at the least, the Autoconf macro could omit those standard locations (as a hack to avoid needing to know more). But even then, the macro is not up to its task at all. Libtool has hardcode_libdir_flag_spec and hardcode_libdir_separator to describe what this macro would need to know. This information is also encoded in the config.rpath file from gettext's autoconf-lib-link. Libtool offers to users the `-R PATH' interface. But for example, the macro will simply not add a run path on platforms whose compiler drivers do not understand `-R PATH', _even_ iff the package in question happens to use libtool in the end (which always understands `-R PATH'). OTOH, whether or not the package uses Libtool, one issue with the macro is that some systems' linkers will not like to be passed several run path arguments but rather one argument with a list of paths. I think this will happen with $host_os matching `sysv5* | sco3.2v5* | sco5v6*' for example. My work on this is incomplete yet, unfortunately, as it lacks a patch and a good idea how to resolve the latter problems within Autoconf. Probably, the easiest thing is to factor out the hardcoding part into a macro that can make use of more knowledge (by depending on Libtool, or config.rpath, for example). Cheers, Ralf
