Re: components_4_64 python Test_Class Build Fails

[Simon Wright]

Roger Mc <roge...@gmail.com> writes:

> Mac OSX Monterey
> Trying to build Test_Class fails with
> /System/Volumes/Data/Ada_Source/components_4_64/python-examples/class/test_class
> dyld[89915]: Library not loaded:
> '/Library/Frameworks/Python.framework/Versions/3.8/Python'
> Referenced from:
> '/System/Volumes/Data/Ada_Source/components_4_64/python-examples/class/test_class'
> Reason: tried:
> '/Library/Frameworks/Python.framework/Versions/3.8/Python' (no such
> file),
> '/System/Library/Frameworks/Python.framework/Versions/3.8/Python' (no
> such file)
>
> I have set the gpr Linker item to
> -F/usr/local/Cellar/pyt...@3.10/3.10.5/Frameworks
> but this does not fix th problem

Not sure I've ever seen /System/Volumes/Data at the start of a path
before! would have expected just /Ada_Source.

Which compiler are you using?

I don't know what triggers that message about
/Library/Frameworks/Python.framework/Versions/3.8/Python,
you'd need to be running a fairly old compiler - if it's one of mine
it'd have to be GCC 10.1.0, otherwise it won't look in
/Library/Frameworks at all.

If your homebrew setup is like mine, you could just say
-F/usr/local/Frameworks, but you have to say _which_ framework, i.e.
-framework python (or maybe -framework Python, probably better).

I built this using GNATstudio, GCC 12.1.0, x86_64 Monterey 12.6,
Atomic_Access auto,
Development Debug,
Legacy Ada2012,
Object_Dir nested,
Target_OS OSX,
Tasking Multiple,
Traced_Objects Off,
arch x86_64

and it linked without issue. Didn't run,
Error: raised ADA.IO_EXCEPTIONS.USE_ERROR : Failed to load Python DLL "libpython3.so"

[Dmitry A. Kazakov]

Right, because it is obviously wrong since Python under OSX looks quite
different from Linux. I mindlessly copied Linux implementation. Now I
finally have an opportunity to fix it! (:-))

BTW, what are you "posh guys" (:-)) are going to do with M1/2? Is there
GNAT?

Is there any noticeable differences to X86_64 on the Ada level?
Endianness must be same, correct? Alignment/padding inside C structures
when interfacing to Ada?

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[Simon Wright]

"Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:

> BTW, what are you "posh guys" (:-)) are going to do with M1/2? Is
> there GNAT?
>
> Is there any noticeable differences to X86_64 on the Ada level?
> Endianness must be same, correct? Alignment/padding inside C
> structures when interfacing to Ada?

The Macs with Apple silicon (I don't think there's a difference between
M1 & M2 at our level) support, for an unknown number of future OS
iterations, a feature called Rosetta (2) which effectively does
just-in-time translation of x86_64 binaries to aarch64. This is the same
scheme they had for the Power -> Intel transition.

x86_64 GCCs run just fine on Apple silicon, generating x86_64 binaries;
I just ran the Alire gnatprove on my M1 mac mini and it failed in the
same way as on x86_64 (libgmp not where it was expected).

We have a native aarch64 compiler that generates aarch64 binaries, no
noticable difference* (maybe if you got out a stopwatch ...). The only
trouble is that aarch64 binaries can't use x86_64 shared libraries; the
assembler, linker and libraries that Apple provides are
dual-architecture, and some external providers provide the same or offer
the choice at download time.

* a couple of ACATS tests designed to check Storage_Error failed on M1 -
I don't remember how.

[Dmitry A. Kazakov]

On 2022-10-21 21:56, Simon Wright wrote:
> "Dmitry A. Kazakov" <mai...@dmitry-kazakov.de> writes:
>
>> BTW, what are you "posh guys" (:-)) are going to do with M1/2? Is
>> there GNAT?
>>
>> Is there any noticeable differences to X86_64 on the Ada level?
>> Endianness must be same, correct? Alignment/padding inside C
>> structures when interfacing to Ada?
>
> The Macs with Apple silicon (I don't think there's a difference between
> M1 & M2 at our level) support, for an unknown number of future OS
> iterations, a feature called Rosetta (2) which effectively does
> just-in-time translation of x86_64 binaries to aarch64. This is the same
> scheme they had for the Power -> Intel transition.

I see, the DEC Alpha's idea. Nice.

> x86_64 GCCs run just fine on Apple silicon, generating x86_64 binaries;
> I just ran the Alire gnatprove on my M1 mac mini and it failed in the
> same way as on x86_64 (libgmp not where it was expected).
>
> We have a native aarch64 compiler that generates aarch64 binaries, no
> noticable difference* (maybe if you got out a stopwatch ...). The only
> trouble is that aarch64 binaries can't use x86_64 shared libraries; the
> assembler, linker and libraries that Apple provides are
> dual-architecture, and some external providers provide the same or offer
> the choice at download time.

OK, this is same as under Windows. You cannot link against 32-bit DLLs,
you can load them as data only.

> * a couple of ACATS tests designed to check Storage_Error failed on M1 -
> I don't remember how.

Well, the stack frames must be different on aarch64 and X86_64. I never
used aarch64, only armhf. The later is quite a mess. Nothing concrete,
just a feeling that the thing promptly crumples under stress load and
generates Storage_Error just for the sake of saying something on system
trap. Stack backtrace is a permanent fight etc.