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
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.
When a library path contained the library name it was eagerly matched
libfwupd.so.2 => /build/fwupd-1.0.5/build/libfwupd/libfwupd.so.2 (0x00007ffff7bbd000)
^^^^^^^^^^^^^^^^^^^^^^
libgweather-3.so.15 => /build/libgweather-3.28.0/build/libgweather/libgweather-3.so.15 (0x00007ffff7bae000)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
which lead to a broken shared library path in the generated GIR file.
This patch allows the soname on the left-hand side of the arrow to
be matched to avoid the trap of the right-hand side. A negative
lookahead had to be added to select the store path, since only
the first match is taken into account.
libglib-2.0.so.0 => /nix/store/dqlc8y4phlg1hmdbwkhqfwhnxcac88d1-glib-2.56.0/lib/libglib-2.0.so.0 (0x00007ffff6400000)
This will not fix non-GNU platforms, where the soname is not printed
first, but we cannot do much without structured ldd output.
Closes: https://github.com/NixOS/nixpkgs/issues/34988
Includes the patches from macports and fixes an issue with the
`otool -L` output that was causing g-ir-scanner to fail.
The paths in the macports patches have been modified so that they
will work with `patches` in nix (an extra directory level was
added).
Once #7701 gets merged, we have another environment variable called
$outputLib, which then points to another environment variable which is
the final library output.
This was brought up in discussion with @lethalman and @vcunat in:
https://github.com/NixOS/nixpkgs/pull/12558#discussion_r50599813
The closure-size branch is not yet merged into master, so this is only
a preparation and we're still falling back to $out and $lib whenever
$outputLib isn't available.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
As the comment needed explanation, that it's about temporary build
files, this should do better.
Thanks again to @lethalman for pointing that out.
Signed-off-by: aszlig <aszlig@redmoonstudios.org>
After patching up the shared libraries in c420de6 to use absolute paths,
there are still some libraries left which do not get an absolute paths
assigned.
Those libraries are the ones which have an absolute path outside of the
Nix store, so we assume that they're build products of the current build
and make them absolute by prepending "$out/lib" or "$lib/lib" (depending
on whether it's a multiple output derivation or not) to its basename.
So for my test case, the resulting library paths now look 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
/nix/store/...-libblockdev-1.3/lib/libbd_utils.so.0
Which is perfectly fine and everything gets resolved correctly after
importing the library using GI.
However, I didn't test it against other libraries and programs, so this
still needs testing, especially for Darwin.
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>
