I guess forking libtool and relying on that instead is not feasible?

Problem is that libtool gets included in everyone's tarballs, so unless we can convince everyone's distro to take our forked version, it won't help much.

Debian has some clever tricks to deal with it that essentially involve patching-in-place the libtool in the tarball:

  http://wiki.debian.org/RpathIssue

I'm not sure we want to go down that path...

I think it mostly stopped being a problem for them with a change to libtool that stopped using rpath for libraries in directories like /usr/lib.  That obviously doesn't help jhbuild a whole lot...

I understand why having system library directories in the rpath is broken, but what's the problem for jhbuild here?

The problem is that the way in which RPATH was specified is widely recognised to have been a mistake.  Specifically: RPATH is more powerful than LD_LIBRARY_PATH, which is exactly what you don't want.

This is why DT_RUNPATH was introduced (and enabled by --enable-new-dtags): if it is set, then LD_LIBRARY_PATH is searched first.

This mess is why we occasionally get problems when we add symbols to libglib and immediately use them from another library or program in-tree.  Even though libtool's wrapper scripts setup LD_LIBRARY_PATH so that we can successfully run things in-tree, the RPATH of the built binary is pointing at your jhbuild install prefix and you end up linking against the installed version of the library instead of the one in-tree (and end up seeing errors about missing symbols).

libtool works around this issue for shared libraries (but not programs) by linking twice.  You may have noticed this: once for the in-tree one in .libs/ and a second time when you do 'make install'.  afaik, the only reason for this is as a workaround to the mess it causes itself by using rpath.

okay.  It seems that the problem has been solved for binaries too -- the wrapper script actually JIT relinks the executable when you run it... I had to see it myself to believe it:

desrt@moonpix:~/code/glib/gio$ chrpath .libs/glib-compile-schemas 
.libs/glib-compile-schemas: RPATH=/home/desrt/local/lib

desrt@moonpix:~/code/glib/gio$ chrpath .libs/lt-glib-compile-schemas 
open: No such file or directory
elf_open: No such file or directory

desrt@moonpix:~/code/glib/gio$ ./glib-compile-schemas 
You should give exactly one directory name

desrt@moonpix:~/code/glib/gio$ chrpath .libs/lt-glib-compile-schemas 
.libs/lt-glib-compile-schemas: RPATH=/home/desrt/code/glib/glib/.libs:/home/desrt/local/lib

desrt@moonpix:~/code/glib/gio$ rm .libs/lt-glib-compile-schemas glib-compile-schemas.o 

desrt@moonpix:~/code/glib/gio$ ./glib-compile-schemas 
gcc: error: glib-compile-schemas.o: No such file or directoryndesrt@moonpix:~/code/glib/gio$

So I did some more research into this...

There's code that makes its way into the 'configure' script of your module (by way of libtool.m4) that sets a variable called 'sys_lib_dlsearch_path_spec' which gets used by ltmain.sh in order to drop "system library paths" from being -rpath'd in.

It is calculated on Linux in a rather annoying/strange way:

    lt_ld_extra=`awk '/^include / { system(sprintf("cd /etc; cat %s 2>/dev/null", \$2)); skip = 1; } { if (!skip) print \$0; skip = 0; }' < /etc/ld.so.conf | $SED -e 's/#.*//;/^[       ]*hwcap[        ]/d;s/[:,      ]/ /g;s/=[^=]*$//;s/=[^= ]* / /g;s/"//g;/^$/d' | tr '\n' ' '`
    sys_lib_dlsearch_path_spec="/lib /usr/lib $lt_ld_extra"

So basically, open (hardcoded) /etc/ld.so.conf, source it (dealing manually with 'include' lines) and use the result of that, together with /usr/lib and /lib.

There is no mechanism for getting the LD_LIBRARY_PATH into this or manually adding additional directories.

Fortunately(?) the above code contains a pretty typical exploitable security issue: we can convince ./configure to execute arbitrary code depending on the contents of our /etc/ld.so.conf.

1) add the following line to the end of /etc/ld.so.conf:

  include /dev/null;$I_HATE_LIBTOOL

ldconfig has the good sense to ignore this.

2) export I_HATE_LIBTOOL='echo /opt/ca/desrt/gnome-3.8/lib'

This will cause everyone's ./configure script to execute "echo /opt/ca/desrt/gnome-3.8/lib" and add the result to the list of system library paths that are skipped when adding -rpath.

One caveat: the match must be exactly equal to $(prefix)/lib -- so if $prefix was set to '/opt/gnome/' (and then libdir is /opt/gnome//lib) then it won't work.


I'm a bit scared for my system now...

A slightly safer way of doing the same is to add this line instead:

  include $I_HATE_LIBTOOL

and then set I_HATE_LIBTOOL to point at a file containing the desired paths to add.  Still pretty scary (since you could set I_HATE_LIBTOOL to /dev/stdin and cause ./configure to never exit) but not arbitrary-code-execution scary...

Created attachment 294752 [details] [review]
autotools: set lt_cv_sys_lib_dlsearch_path_spec

We can use this to override the default detected libtool runtime search
path.

This will prevent rpath from being set on account of things that are in
jhbuild's libdir (and listed in LD_LIBRARY_PATH).

We only do this on GNU ELF systems.

This patch first needs the one in bug 634617 to be committed.

We could also solve this by adding it as an extra commandline argument to ./configure instead of using an environment variable.  That would have the advantage of increasing its visibility by getting it into the output and into a more visible place in config.log -- just incase something goes wrong and someone is trying to figure out why.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/jhbuild/-/issues/122.