Re: macOS 11 find-libs.mk POC

["Sijmen J. Mulder" <ik%sjmulder.nl@localhost>]

Chris Hanson <cmhanson%eschatologist.net@localhost> wrote:
> On Aug 23, 2020, at 4:40 AM, Sijmen Mulder <ik%sjmulder.nl@localhost> wrote:
> > 
> > macOS 11 (now in beta) no longer contains shared library files like
> > libc.dylib, libcurses.dylib etc. Instead it ships a pregenerated
> > linker cache. This means we can no longer check for built in libraries
> > by going through the library directories as we do in
> > mk/buildlink3/find-libs.mk. Apple's documentation suggests using
> > dlopen(), which works as usual and has all the old paths mapped.
> 
> Rather than testing what libraries _are installed in the OS_ you should
> be testing _what libraries can be linked against when building_. All of
> the tools have looked in SDKs for headers and library stubs for
> something like a decade and a half at this point, so just passing (say)
> -lz still works just fine and you don't have to care where exactly
> libz.tbd is.

I agree this is the right approach in principle - if you want to see if
a library can be linked, try to link it. However it's my understanding
that this functionality needs to be available before we have selected a
compiler.

Your point about .tbd suggests another possibility, which is to check
the SDK's usr/lib for those. Another alternative which I forgot to
mention is to default PREFER_PKGSRC everything on Darwin.

So the options then, in my order of preference:

 1. Testing by compiling (configure-style), as you suggest, if at all
    possible.
 2. Look for .tdb in the SDK instead of installed .dylibs in /usr/lib.
 3. Testing with dlopen().
 4. Don't use built in on Darwin.
 5. Extract list of libraries from the linker cache.

Sijmen