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

[Brook Milligan <brook%nmsu.edu@localhost>]

> On Feb 16, 2020, at 11:40 AM, Brook Milligan <brook%nmsu.edu@localhost> wrote:
> 
> [864/1124] Generating plugin-resources.c with a custom command.
> FAILED: gio/tests/plugin-resources.c 
> /Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/glib-2.62.3/output/gio/glib-compile-resources --target=gio/tests/plugin-resources.c --sourcedir=/Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/glib-2.62.3/gio/tests --generate-source --c-name _g_plugin ../gio/tests/test4.gresource.xml
> dyld: Library not loaded: @rpath/libgio-2.0.0.dylib
>  Referenced from: /Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/glib-2.62.3/output/gio/glib-compile-resources
>  Reason: image not found
> ninja: build stopped: subcommand failed.
> *** Error code 1

To follow up on this and the wrapper issue, it is clear from what I describe below that the wrappers need to be modified if we wish to solve this problem.

To recap: cd pkgsrc/devel/glib2 && bmake fails as above on MacOS with SIP enabled (but not when disabled).  The offending program is gio/glib-compile-resources which is run from an uninstalled location during the build process.  Here are the relevant linking commands in .work.log:

[*] cc -o gio/glib-compile-resources 'gio/6ae6c9e@@glib-compile-resources@exe/gvdb_gvdb-builder.c.o' 'gio/6ae6c9e@@glib-compile-resources@exe/glib-compile-resources.c.o' -I/Users/brook/pkg-2019Q4/include -I/Users/brook/pkg-2019Q4/include/python3.7 -L/usr/lib -L/Users/brook/pkg-2019Q4/lib -Wl,-dead_strip_dylibs -Wl,-undefined,error -Wl,-headerpad_max_install_names -Wl,-framework,CoreFoundation -Wl,-framework,Carbon -O2 gio/libgio-2.0.0.dylib gmodule/libgmodule-2.0.0.dylib glib/libglib-2.0.0.dylib gobject/libgobject-2.0.0.dylib -lintl -Wl,-headerpad_max_install_names '-Wl,-rpath,@loader_path/' '-Wl,-rpath,@loader_path/../glib' '-Wl,-rpath,@loader_path/../gobject' '-Wl,-rpath,@loader_path/../gmodule' -Wl,-rpath,/Users/brook/pkg-2019Q4/lib -Wl,-rpath,/usr/lib

<.> /usr/bin/clang -m64 -o gio/glib-compile-resources 'gio/6ae6c9e@@glib-compile-resources@exe/gvdb_gvdb-builder.c.o' 'gio/6ae6c9e@@glib-compile-resources@exe/glib-compile-resources.c.o' -I/Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/.buildlink/include -I/Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/.buildlink/include/python3.7 -L/Volumes/NetBSD-boost/NetBSD/pkgsrc-2019Q4/pkgsrc/devel/glib2/work/.buildlink/lib -Wl,-dead_strip_dylibs -Wl,-undefined -Wl,error -Wl,-headerpad_max_install_names -Wl,-framework -Wl,CoreFoundation -Wl,-framework -Wl,Carbon -O2 gio/libgio-2.0.0.dylib gmodule/libgmodule-2.0.0.dylib glib/libglib-2.0.0.dylib gobject/libgobject-2.0.0.dylib -lintl -Wl,-headerpad_max_install_names -Wl,-rpath,/Users/brook/pkg-2019Q4/lib -Qunused-arguments

Note that all the -Wl,-rpath,@loader_path options are stripped by the wrappers.

Once the build fails, however, if a modified version of the second (i.e., <.>) command is run in ${WRKSRC}/output to rebuild gio/glib-compile-resources, a subsequent continuation of the build completes successfully.  Either of two modifications are sufficient.  (i) Add -Wl,-rpath,${WRKSRC}/output… (one per removed @loader_path entry) entries to the second linking command listed above.  (ii) Add the -Wl,-rpath,@loader_path entries just as they originally were (i.e., untransformed).  Note that after this change the installed application has correct absolute paths to its library dependencies and there is no vestige of @loader_path.

This seems to demonstrate both that the wrappers are causing a problem by removing these command line options during the build, and that a straightforward fix (allowing them to propagate untransformed) will solve the problem.  (It might also be necessary to handle @executable_path and similar if other packages use those.)

Can we add transform rules for the wrappers to solve this?

What is the best mechanism for allowing -Wl,-rpath,@foo_path options to remain untransformed by the wrappers?

Should there be a mechanism to explicitly request that these be passed through (like BUILDLINK_PASSTHRU), which could be conditionally requested in package Makefiles?

Unfortunately, the wrapper code is a bit dense for me, so I would _greatly_ appreciate someone with better knowledge stepping in.

Thanks a lot.  I hope this focuses our attention in ways that have eluded this conversation in the past.

Cheers,
Brook