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/python@3.10/3.10.5/Frameworks
but this does not fix th problem

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Roger Mc <rogermcm2@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/python@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"

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-21 18:52, Simon Wright wrote:

Roger Mc <rogermcm2@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/python@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"

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2022-10-21 21:56, Simon Wright wrote:

"Dmitry A. Kazakov" <mailbox@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.

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

"Dmitry A. Kazakov" <mailbox@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.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)