autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: AC_PATH_XTRA and -rpath


From: Ralf Wildenhues
Subject: Re: AC_PATH_XTRA and -rpath
Date: Fri, 25 Aug 2006 09:22:20 +0200
User-agent: Mutt/1.5.12 (2006-08-10)

Sorry for reviving a slightly old thread...

* Paul Eggert wrote on Mon, Jul 17, 2006 at 11:41:13PM CEST:
> Patrick Welche <address@hidden> 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




reply via email to

[Prev in Thread] Current Thread [Next in Thread]