This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: org.sourceware.binutils@pooryorick.com
- From: Matt Rice <ratmice at gmail dot com>
- To: org dot sourceware dot binutils at pooryorick dot com
- Cc: binutils at sourceware dot org
- Date: Tue, 19 Oct 2010 04:42:48 -0700
- Subject: Re: org.sourceware.binutils@pooryorick.com
- References: <20101019100526.GC31607@web106.webfaction.com>
On Tue, Oct 19, 2010 at 3:05 AM,
<org.sourceware.binutils@pooryorick.com> 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.
>
> I have documented specific cases of trouble here (including building binutils itself):
>
> ? ?http://ynform.org/w/Pub/TheTroubleWithOrigin
>
> Because of all these troubles, I have resorted to using a pattern like ZZZZZZZ,
> and then, when the build is finished, replacing this pattern in the ELF files
> with $ORIGIN. ?It's a hack that would be nice to avoid.
>
> For the innovation of $ORIGIN to succeed, it needs to be more compatible with
> the GNU toolchain. ?Last year, Dave Korn pondered providing some
> altenate token for binutils to translate into $ORIGIN (http://sourceware.org/ml/binutils/2009-05/msg00258.html).
>
> How about a pattern like the following, which avoids the pitfalls mentioned above:
>
> //ORIGIN/
>
> Or, if that is not improbable enough:
>
> ///ORIGIN/
>
> It would only need to be recognized at the beginning of any path to be included
> in RPATH/RUNPATH list.
>
i recall another thread discussing this, also containing proposed replacements
http://sourceware.org/ml/binutils/2009-10/msg00257.html
according to elf these can also appear in DT_NEEDED entries,
I'm embedding substitution sequences (although not ORIGIN
specifically) into DT_SONAME which then gets
pulled into the DT_NEEDED entry.
(I don't see elf saying anything about DT_SONAME, but it is discussing
the effect of the substitution sequence as interpreted by the dynamic
linker, and I can't think of any other way one would achieve embedding
a subst seq into a DT_NEEDED.)