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

[js-pkgsrc%heap.zone@localhost]

> Ok, but this just takes us back a step to where it's unclear why some
> people are running into issues and others aren't.  Any ideas?

As this is Apple, my guess is some weird side effect.

> I removed the --disable-swift argument and mpv builds and runs for me,
> it's linked to a bunch of libraries under /usr/lib/swift.  Is there
> some particular usage I should be testing?

Try playing any video file.

> What's next on this list of "packages left and right"?  I'm happy to
> continue fixing them, it's vastly preferable to yet more arguments
> about the wrappers.

I think it would be vastly more preferable to change the wrappers :).

The problem seems to be that the wrapper does not like the magic paths that begin with @. Some of them are basically almost equivalent to an absolute path: E.g. @executable_path/../lib is pretty much an absolute path once installed. These really should not be stripped.

A common pattern on ELF systems is to have an rpath and then use LD_LIBRARY_PATH during build. On macOS, however, rpath behaves vastly differently and this won't work. Mach-O libraries also have an install name. This can be used to come to something much closer to how rpath behaves on other system.

E.g. if the goal is to have a library that is both available during build and after installation, on ELF systems, you would set an rpath for every application linking against it, and would use LD_LIBRARY_PATH during build. On macOS, however, instead, you would set an install_path *on the library*. Applications then record this install path, and look for the library there. Except if they have DYLD_LIBRARY_PATH set: Then that is used. So you just set DYLD_LIBRARY_PATH during build.

Here's how I solved this in my build system:

https://git.nil.im/buildsys.git/tree/m4/buildsys.m4#n168
https://git.nil.im/buildsys.git/tree/m4/buildsys.m4#n262

It was quite painful to find something that absolutely ever works. This is the only solution that I found over the years that works from 10.5 to 10.15. Because, of course, dyld was changed significantly in 10.6. It should theoretically also work on 10.4, but I have not tested.

> I'm using my binary package repo from
> https://pkgsrc.joyent.com/install-on-osx/ to install the required
> build dependencies, but that shouldn't affect things.

I really would not bet on that. Build those yourself and then compare the output of otool.

> It's also worth mentioning for the record that LD_LIBRARY_PATH does in
> fact still continue to function as expected on macOS 10.15, contrary
> to claims earlier in this thread that only DYLD_* was supported.

Interesting. This indeed seems to work on 10.15. This definitely did not work in older versions. I wonder when this was introduced. It's also still not documented in dyld(1), so not the best idea to rely on this behavior.

-- 
Jonathan