Updated the shlib patches:
- Upstream now forces basename in sanitize_shlib_path(lib) if the system isn't
darwin. We patch the function to always prefer absolute paths
- Due to the above we no longer need the macos patch
- `sanitize_shlib_path` is applied after `resolve_from_ldd_output` so we need to
apply `fallback_libpath` afterwards too (else we get stuff like
`/nix/store/...@rpath/foo.dylib` on darwin)
- Note that the `fallback_path` no longer have any unit tests
https://gitlab.gnome.org/GNOME/gobject-introspection/blob/1.60.1/NEWS
We patch gobject-introspection somewhat heavily, so add some unit tests that
will catch potential errors when we're eg. updating the patches.
There's two tests:
- Basic test for absolute nix store paths (testing absolute_shlib_path.patch)
- Test for macos `@rpath` sanitizing, including
fallback_libpath (macos-shared-library.patch)
Upstream now strips absolute paths to their basename on all platforms apart from
Darwin: a41abe1868
To get around this without modifying the basename test we simply pass in
`basename=False` when normally generating gir files.
Resolved the following conflicts (by carefully applying patches from the both
branches since the fork point):
pkgs/development/libraries/epoxy/default.nix
pkgs/development/libraries/gtk+/3.x.nix
pkgs/development/python-modules/asgiref/default.nix
pkgs/development/python-modules/daphne/default.nix
pkgs/os-specific/linux/systemd/default.nix
Cairo does not provide its own GObject bindinds so they are provided
by gobject-introspection package. Unfortunately, this means that if we
want to use the absolute path, we need gi to depend on cairo, which
increases the closure size from 41M to 56M. We will probably want
to split the typelib into a separate output.
Closes: #34080
This is a squash commit of the joint work from:
* Jan Tojnar (@jtojnar)
* Linus Heckemann (@lheckemann)
* Ryan Mulligan (@ryantm)
* romildo (@romildo)
* Tom Hunger (@teh)
Stop using obsolete `otool` package, preferring `cctools` (which
includes otool), on darwin.
Remove autoconf & automake from reqs, as they were unused.
Fixes#12670
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>
- there were many easy merge conflicts
- cc-wrapper needed nontrivial changes
Many other problems might've been created by interaction of the branches,
but stdenv and a few other packages build fine now.
