From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00
	autolearn=unavailable autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Simon Wright <simon@pushface.org>
Newsgroups: comp.lang.ada
Subject: Re: GNAT CE 2019 macOS
Date: Thu, 30 May 2019 20:34:44 +0100
Organization: A noiseless patient Spider
Message-ID: <lyef4f91nv.fsf@pushface.org>
References: <0001HW.22A01E95014EDF4A7000076A12EF@news.individual.net>
Mime-Version: 1.0
Content-Type: text/plain
Injection-Info: reader02.eternal-september.org;
 posting-host="a7df9e4056d1dc48c81feeace501bc23";
	logging-data="27111"; mail-complaints-to="abuse@eternal-september.org";
	posting-account="U2FsdGVkX184lUPPT4dVEG5Jcj+r2tseqth5m83S9jk="
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (darwin)
Cancel-Lock: sha1:OxxZLHJm3ezWp7l4HHN2fp+FjMw=
	sha1:Io5b1rhkn0Tj1WDJb9yj4i7MB20=
Xref: reader01.eternal-september.org comp.lang.ada:56416
Date: 2019-05-30T20:34:44+01:00
List-Id: <comp.lang.ada>

Bill Findlay <findlaybill@blueyonder.co.uk> writes:

>> gnatlink /Users/wf/mekhos/MacOSX/e.ali -funwind-tables
>> -fdata-sections -ffunction-sections -mtune=native -fno-stack-check
>> -fomit-frame-pointer -flto -O3
> ./quad_div.o -Wl,-dead_strip -Wl,-dead_strip -flto
>
>> ld: library not found for -lSystem
>> collect2: error: ld returned 1 exit status
>> gnatmake: *** link failed.
>
> -lSystem ??

I've had a discussion about this with AdaCore.

The problem they are addressing is that Apple are moving towards having
system includes only in the SDKs rather than in /usr/include; see [1],
which says "As a workaround, an extra package is provided which will
install the headers to the base system. In a future release, this
package will no longer be provided".

"this package" is the one I reference at [2].

AdaCore's approach is to build the compiler with a "system root" that
references the SDK in situ; the actual link takes place with

/usr/bin/ld -syslibroot
/Library/Developer/CommandLineTools/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/
...

and, unfortunately for us, that's the full Xcode and not the
CommandLineTools subset; so if you only have the CommandLineTools, ld
looks for libSystem.dylib in a non-existent directory.

One approach is to build with -largs -Wl,-syslibroot,/
Another one is to install the full Xcode.
I guess Xcode is the way to go.

For the future
--------------

I don't think it's possible to have multiple syslibroots.

I don't think the GCC developers would be happy with building knowledge
of xcode-select into the compiler, so it could make the same runtime
choices as Apple tools.

Since the SDKs really only impact the includes, at any rate as long as
you're on macOS and not iOS, I'm wondering whether it'd be possible to
add both SDK include paths to GCC's include paths and avoid the
syslibroot impact on libraries.

Nothing yet about this on the GCC mailing lists, that I can see.

[1] https://developer.apple.com/documentation/xcode_release_notes/xcode_10_release_notes#3035624
[2] https://forward-in-code.blogspot.com/2018/11/mojave-vs-gcc.html