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=-0.3 required=5.0 tests=BAYES_00,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
Path: 
 eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!news.unit0.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Bill Findlay <findlaybill@blueyonder.co.uk>
Newsgroups: comp.lang.ada
Subject: Re: GNAT CE 2019 macOS
Date: Thu, 30 May 2019 21:33:45 +0100
Organization: none
Message-ID: <0001HW.22A075A9016347FD7000076A12EF@news.individual.net>
References: <0001HW.22A01E95014EDF4A7000076A12EF@news.individual.net>
 <lyef4f91nv.fsf@pushface.org>
Reply-To: findlaybill@blueyonder.co.uk
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Trace: individual.net tRNG2AaDq9egnqQFkGK6hgMrcSTZYkna5RhigEUYXULxUMqR7q
X-Orig-Path: not-for-mail
Cancel-Lock: sha1:Nn4liWFSjIbPNSPnMxyBgmmV1fA=
User-Agent: Hogwasher/5.20
Xref: reader01.eternal-september.org comp.lang.ada:56417
Date: 2019-05-30T21:33:45+01:00
List-Id: <comp.lang.ada>

On 30 May 2019, Simon Wright wrote
(in article <lyef4f91nv.fsf@pushface.org>):

> 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/M
> acOSX.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_rel
> ease_notes#3035624
> [2] https://forward-in-code.blogspot.com/2018/11/mojave-vs-gcc.html
Now downloading the full Xcode 8-(
...
...
That worked. 8-)

Many thanks for the info, Simon.

-- 
Bill Findlay