GNAT CE 2019 macOS

GNAT CE 2019 macOS

[Bill Findlay]

> 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 ??

-- 
Bill Findlay

Re: GNAT CE 2019 macOS

[Simon Wright]

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

Re: GNAT CE 2019 macOS

[Bill Findlay]

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

Re: GNAT CE 2019 macOS

[Simon Wright]

I did something on this, written up here:
https://forward-in-code.blogspot.com/2019/06/macos-software-development-kit-changes.html