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

[js-pkgsrc%heap.zone@localhost]

> I guess that's the problem then.  I wasn't aware it also disabled use
> of {DY,}LD_LIBRARY_PATH.

LD_LIBRARY_PATH is completely ignored on macOS and it has never been any different.

DYLD_LIBRARY_PATH is most definitely not disabled by SIP - my machine has SIP enabled and my own software uses it to make sure tests are run against the just built library instead of the installed one and it works just fine. There seems to be a grave misunderstanding here in what SIP disables: SIP does not disable DYLD_LIBRARY_PATH, it only ignores it for binaries *that are protected by SIP*. Nothing built by pkgsrc is protected by SIP.

The problem with the meson-based packages not building on macOS is, as I finally figured out, indeed pkgsrc-related: Building these outside of pkgsrc works perfectly fine, so I guess some required flags are stripped by the wrapper.

An alternative that I used before I figured out the problem are the wrappers is:
(using zsh, so ** means recursive)
$ install_name_tool -id /opt/pkg/lib/libfoo.0.dylib **/libfoo.0.dylib
$ cp **/libfoo.0.dylib /opt/pkg/lib
$ bmake
$ rm /opt/pkg/lib/libfoo.0.dylib
$ bmake install

> It seems unsafe to just drop things, vs throwing an error, as it means
> that fighting with upstream build systems ends up silently not doing
> what was asked.   But that's probably too much tilting at windmills.

Indeed. It's breaking macOS packages left and right. Another example is that mpv currently uses --disable-swift because Swift does not work with the wrappers. But mpv no longer maintains the non-Swift version, so is completely broken right now (crash on start).

> So, should the guidance be, “Disable SIP on MacOS”?  If so, that needs to be documented somewhere.

That seems entirely unreasonable. SIP has been around for many years, and suggesting users to disable SIP is a guaranteed huge shitstorm these days.

> Arguably, macOS is wrong to ignore LD_LIBRARY_PATH for a library 

No, it is absolutely in the right here. LD_LIBRARY_PATH is not portable and specific to ld.so. macOS is not even using ELF, and dyld uses DYLD_LIBRARY_PATH instead.

-- 
Jonathan