This is the mail archive of the
libc-help@sourceware.org
mailing list for the glibc project.
Re: the trouble with $ORIGIN
On Tue, Oct 19, 2010 at 07:11:03PM -0400, Carlos O'Donell wrote:
> On Mon, Oct 18, 2010 at 8:21 PM, <Yorick> wrote:
> > For the past couple of years, I've been working on building a software
> > collection which is install-path-agnostic. ?It relies on the use of $ORIGIN in
> > every shared object. ?The dollar sign in "$ORIGIN", though, has proven
> > hazardous. It must be escaped so that it doesn't get eaten by autoconf
> > (configure). ?Then it must be escaped some more so it doesn't get eaten by
> > Make. ?But if Makefile calls make recursively, passing LDFLAGS on the command
> > line, it must be escaped further. ?Then, it must be escaped even more depending
> > on the whims of the shell scripts that may run as part of a software build.
> > Finally, it can easily get lost as programs try to communicate their
> > configuration settings to other builds. ?For example, the gtk+ "configure"
> > script calls "cups-config --libs", the output of which is then interpolated by
> > autoconf into gtk+/Makefile between double quotes. ?If the output contains
> > "$ORIGIN", or rather, due to Make escaping, "\$$ORIGIN", $$ ends up being
> > interpreted as the pid of the current shell.
>
> Can you use a compiler spec file to do this without having to pass
> around $ORIGIN?
>
That sounds like a good idea. I'll try it. Thanks!
It seems that this has already been brought up on the binutils list a couple of
times recently. Maybe they'll implement some alternative.
--
Yorick