* components_4_64 python Test_Class Build Fails @ 2022-10-21 0:39 Roger Mc 2022-10-21 16:52 ` Simon Wright 0 siblings, 1 reply; 5+ messages in thread From: Roger Mc @ 2022-10-21 0:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: components_4_64 python Test_Class Build Fails 2022-10-21 0:39 components_4_64 python Test_Class Build Fails Roger Mc @ 2022-10-21 16:52 ` Simon Wright 2022-10-21 18:39 ` Dmitry A. Kazakov 0 siblings, 1 reply; 5+ messages in thread From: Simon Wright @ 2022-10-21 16:52 UTC (permalink / raw) 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" ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: components_4_64 python Test_Class Build Fails 2022-10-21 16:52 ` Simon Wright @ 2022-10-21 18:39 ` Dmitry A. Kazakov 2022-10-21 19:56 ` Simon Wright 0 siblings, 1 reply; 5+ messages in thread From: Dmitry A. Kazakov @ 2022-10-21 18:39 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: components_4_64 python Test_Class Build Fails 2022-10-21 18:39 ` Dmitry A. Kazakov @ 2022-10-21 19:56 ` Simon Wright 2022-10-21 20:14 ` Dmitry A. Kazakov 0 siblings, 1 reply; 5+ messages in thread From: Simon Wright @ 2022-10-21 19:56 UTC (permalink / raw) "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. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: components_4_64 python Test_Class Build Fails 2022-10-21 19:56 ` Simon Wright @ 2022-10-21 20:14 ` Dmitry A. Kazakov 0 siblings, 0 replies; 5+ messages in thread From: Dmitry A. Kazakov @ 2022-10-21 20:14 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2022-10-21 20:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-10-21 0:39 components_4_64 python Test_Class Build Fails Roger Mc 2022-10-21 16:52 ` Simon Wright 2022-10-21 18:39 ` Dmitry A. Kazakov 2022-10-21 19:56 ` Simon Wright 2022-10-21 20:14 ` Dmitry A. Kazakov
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox