Home Original page

org.sourceware.binutils@pooryorick.com

Matt Rice ratmice@gmail.com
Tue Oct 19 11:42:00 GMT 2010 
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.)
More information about the Binutils mailing list