Fixes#97. In essence, the problem is that some packages in Nixpkgs have
RPATHs pointing to both $NIX_BUILD_TOP and $out, e.g.:
/tmp/nix-build-openldap-2.4.44.drv-0/openldap-2.4.44/libraries/libldap_r/.libs
/tmp/nix-build-openldap-2.4.44.drv-0/openldap-2.4.44/libraries/liblber/.libs
/nix/store/bfkmdxmv3a3f0g3d2q8jkdz2wam93c5z-openldap-2.4.44/lib
/nix/store/bfkmdxmv3a3f0g3d2q8jkdz2wam93c5z-openldap-2.4.44/lib64
Currently, running `patchelf --shrink-rpath` does the wrong thing by
keeping the /tmp/ paths and deleting the /nix/store ones. Now we can fix
the problem by using
patchelf --shrink-rpath --allowed-rpath-prefixes $NIX_STORE_DIR
in the Nixpkgs fixupPhase instead.
This leads to numerous build failures:
http://hydra.nixos.org/eval/1136585
because ELF interpreter names are not unique (e.g. ld-linux.so.2 is
used on systems other than i686-linux).
* compile locally this test in the no-rpath test
* add tests for prebuilt no-rpath binaries on various ELF platforms
=> ia64 does not work, probably a bug in patchelf. Marking it as XFAIL for now
- add options in AM_INIT_AUTOMAKE to be more strict
and to enable more advanced features (color-tests and parallel-tests)
- rewrite tests/Makefile.am to use automake rules for building program and libraries
=> we can now do:
./bootstrap.sh && mkdir build && cd build && ../configure && make -j distcheck
- use Makefile variables $< (and $@) so that sources are found correctly
- use ${srcdir} in test scripts to find the sources
This allows "make distcheck" to successfully pass
- add options in AM_INIT_AUTOMAKE to be more strict
and to enable more advanced features (color-tests and parallel-tests)
- rewrite tests/Makefile.am to use automake rules for building program and libraries
=> we can now do:
./bootstrap.sh && mkdir build && cd build && ../configure && make -j distcheck
- use Makefile variables $< (and $@) so that sources are found correctly
- use ${srcdir} in test scripts to find the sources
This allows "make distcheck" to successfully pass
directory to the RPATH of an executable doesn't cause it to be used
for resolving dependencies of libraries, only the dependencies of
the executable itself. So don't rely on that. A better fix would
be to support --set-rpath on libraries, but that's a lot harder.
Tuomas Tynkkynen