[Top][All Lists]

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

Re: RPATH on x86_64?

From: Ralf Wildenhues
Subject: Re: RPATH on x86_64?
Date: Fri, 3 Mar 2006 08:54:18 +0100
User-agent: Mutt/1.5.11

[ note: list lag is still days: see ]

* 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

> 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
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

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.


reply via email to

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