Re: MacOS issues with devel/glibc2, devel/gobject-introspection, devel/pango

[Greg Troxel <gdt%lexort.com@localhost>]

Brook Milligan <brook%nmsu.edu@localhost> writes:

> I am returning to the problem of meson and Gnome on MacOS.  At least
> three packages (devel/glibc2, devel/gobject-introspection, and
> devel/pango) build introspection data during the package builds using
> programs also compiled during the package build.  These programs are
> built with meson and include rpath information in the
> binaries/libraries.  Because of the way this works, the uninstalled
> binaries will not run on MacOS because the rpath information is
> incorrect at that point and the loader complains about “image not
> found”.

This sounds like a meson bug.  libtool has a scheme to link the
libraries in the build tree so they'd work there (for tests, generally,
but use as a build tool is sort of the same), and then relinks them for
installation.

> If the same packages are built with Apple’s security SIP disabled,
> everything works fine.  I assume that this is because the use of, for
> example, LD_LIBRARY_PATH and friends, is not ignored when SIP is
> disabled but that when it is enabled the path to the not-yet-installed
> libraries is ignored.

Interesting.  I wonder how upstream (glib2 - guessing you don't mean
glibc2!) sees this.   I am guessing meson expects to use LD_LIBRARY_PATH
to find the libraries that the libraries don't actually reference, and
if this is really a macSIP thing, would expect that the upstream build
without pkgsrc would fail as well.

> How shall this issue be addressed by pkgsrc?  Does anyone know how to
> make MacOS have the right information so that it just works?  Should
> these be marked as broken on some versions of MacOS (I’m doing this on
> Catalina) so at least we can have a sensible error message?

My approach would be

  - Look into how upstream deals with this.  Do the upstream packages
    build on macOS with SIP if built in the way upstream says?

  - See if it's possible to set the rpath info at/after build to work in
    the tree, and then redo it for install

  - think about splitting the package to make the gir-compiler or
    whatever separate

  - convert glib2 back to autoconf, because the new "these are better
    than autoconf" build systems have so far failed to actually fully
    reinvent autoconf

(ok, the last one is just trolling)