ANN: GCC 10.1.0 for macOS

ANN: GCC 10.1.0 for macOS

[Simon Wright]

Native and cross-arm-eabi compilers now available at
https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/10.1.0/

Re: ANN: GCC 10.1.0 for macOS

[Bill Findlay]

On 16 May 2020, Simon Wright wrote
(in article <lyd0749hde.fsf@pushface.org>):

> Native and cross-arm-eabi compilers now available at
> https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/10.1.0/

Hi Simon.
Many thanks for that.

After battling GateKeeper, I get the error:

> ==============Error messages for source file: ../Source/magtape_data.ads 28.
> with Static_Predicate =>  slice_size_limit <= 255;
> | >>>  aspect specifications not allowed here

in the file:

package magtape_data is

-- 
-- slice_size_limit is set so that the slice size field fits into 1 byte,
-- thus avoiding endian-ness and portability issues.
-- 

slice_size_limit : constant := 128
with Static_Predicate =>  slice_size_limit <= 255; --<<<<<  HERE

max_MT_record_length : constant := slice_size_limit + 3;

subtype LBM_markers is Character
with Static_Predicate =>  LBM_markers in '@' | 'A' | 'H' | 'I';

-- 
-- These subtypes are used in the post-processing of OUT 8 spool tapes.
-- 

subtype OUT8_selection_characters is Character
with Static_Predicate =>  OUT8_selection_characters in '#' | '_' | '@' | '"';

end magtape_data;

This compiles with GNAT CE 2019.
Looking at it again, I wonder whether predicates *are* allowed for constants?

Apart from that, and some new warnings about fields being named in
a different order between a record declaration and its rep. spec.,
my ~25K SLOC KDF9 emulator compiles and passes its regression tests.

-- 
Bill Findlay

Re: ANN: GCC 10.1.0 for macOS

[Simon Wright]

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

> This compiles with GNAT CE 2019.
> Looking at it again, I wonder whether predicates *are* allowed for constants?

3.3.2(2) doesn't allow aspect specifications on named numbers.

I poked around a bit and got "predicate can only be specified for a
subtype"

> Apart from that, and some new warnings about fields being named in
> a different order between a record declaration and its rep. spec.,
> my ~25K SLOC KDF9 emulator compiles and passes its regression tests.

Good news!

Re: ANN: GCC 10.1.0 for macOS

[Vincent DIEMUNSCH]

Le samedi 16 mai 2020 à 14:47:15 UTC+2, Simon Wright a écrit :
> Native and cross-arm-eabi compilers now available at 
> https://sourceforge.net/projects/gnuada/files/GNAT_GCC%20Mac%20OS%20X/10.1.0/

Hello Simon,

I just switched to macOS Big Sur, and unfortunately I have troubles with GNAT gcc.
Here is a simple example, but I get the same error compiling from GPS using GPRBuild.

% gnatmake controle.adb
gcc -c controle.adb
gcc -c crc_type.adb
gnatbind -x controle.ali
gnatlink controle.ali
ld: library not found for -lSystem
collect2: error: ld returned 1 exit status
gnatlink: error when calling /opt/gcc/10.1.0/bin/gcc
gnatmake: *** link failed.

Any idea about a solution ?

Regards,

Vincent

Re: ANN: GCC 10.1.0 for macOS

[Simon Wright]

Vincent DIEMUNSCH <vincent.diemunsch@gmail.com> writes:

> I just switched to macOS Big Sur, and unfortunately I have troubles
> with GNAT gcc.
> Here is a simple example, but I get the same error compiling from GPS
> using GPRBuild.
>
> % gnatmake controle.adb
> gcc -c controle.adb
> gcc -c crc_type.adb
> gnatbind -x controle.ali
> gnatlink controle.ali
> ld: library not found for -lSystem
> collect2: error: ld returned 1 exit status
> gnatlink: error when calling /opt/gcc/10.1.0/bin/gcc
> gnatmake: *** link failed.

I came across this but managed to forget to do anything about it, very
sorry.

You make remember that at Mojave, & with the inclusion of software
development kits (SDKs) for different targets such as iPhone, Apple
Watch, Apple decided not to include the system C headers in
/usr/include; their own compilers know where to find them inside the
SDKs, a problem which I addressed at [1] & [2].

With Big Sur they've done the same for system libraries, which you'd
have expected to find in /usr/lib.

I don't have Big Sur running on this box at the moment (it's the only
one I own that can!), so can't test this, but the workround I found was
to say, assuming you have Xcode & not the Command Line Tools installed,

  gnatmake controle.adb -largs
  -L/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib

(wow)

You're most welcome to raise an issue at [2].

[1]
https://forward-in-code.blogspot.com/2019/06/macos-software-development-kit-changes.html
[2] https://github.com/simonjwright/macos-sdks-vs-gcc

Re: ANN: GCC 10.1.0 for macOS

[Luke A. Guest]

On 04/12/2020 14:14, Simon Wright wrote:
> Vincent DIEMUNSCH <vincent.diemunsch@gmail.com> writes:
> 
> I don't have Big Sur running on this box at the moment (it's the only
> one I own that can!), so can't test this, but the workround I found was

*cough* VM *cough*

Re: ANN: GCC 10.1.0 for macOS

[Simon Wright]

"Luke A. Guest" <laguest@archeia.com> writes:

> On 04/12/2020 14:14, Simon Wright wrote:
>> Vincent DIEMUNSCH <vincent.diemunsch@gmail.com> writes:
>> I don't have Big Sur running on this box at the moment (it's the
>> only
>> one I own that can!), so can't test this, but the workround I found was
>
> *cough* VM *cough*

Well, yes ... maybe