If no config.nix.storeDir has been set, don't fall back to "/nix/store"
but use builtins.storeDir instead so we always should end up with the
correct store path no matter whether config.nix.storeDir has been set.
Thanks to @lethalman for pointing this out.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
The gi-r-scanner is generating a list of shared libraries that are
referenced in the shared-library attribute of the <namespace/> element
of the GIR file. However, this attribute only contains the names of the
libraries and not the full store paths, like for example while preparing
to package libblockdev, the following items were included in the
shared-library attribute:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
libm.so.6
libdmraid.so.1.0.0.rc16
libbd_utils.so.0
Unfortunately, loading such a library without setting LD_LIBRARY_PATH is
going to fail finding libm.so.6 and libdmraid.so.1.0.0.rc16.
Now the first attempt at solving this was to put absolute paths of all
the libraries referenced in the shared-library attribute, but this also
led up to including paths of build-time shared objects into that
attribute:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
/nix/store/...-glibc-2.21/lib/libm.so.6
/nix/store/...-dmraid-1.0.0.rc16/lib/libdmraid.so.1.0.0.rc16
/tmp/nix-build-libblockdev-1.3.drv-0/.../utils/.libs/libbd_utils.so.0
This of course is not what we want, so the final solution is to only
use the absolute path whenever it is a Nix path and leave the library
name as-is if the path doesn't reside within the store, like this:
/nix/store/...-libblockdev-1.3/lib/libblockdev.so.0
/nix/store/...-glibc-2.21/lib/libm.so.6
/nix/store/...-dmraid-1.0.0.rc16/lib/libdmraid.so.1.0.0.rc16
libbd_utils.so.0
The downside of this approach is that if not even the output path of the
library is in LD_LIBRARY_PATH, even loading of libbd_utils.so.0 could
fail, so we need to patch the loader as well.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
This is all work of Marc Weber <marco-oweber@gmx.de>, except for a few nitpicks.
Tested space blowup: IMHO negligible to headers and similar stuff,
e.g. the firefox closure (reported by du) grows from 560 to 579 MB.
Saving space should be handled separately,
e.g. we have the multiple-outputs branch.
