Enable aarch64 builds#82
Conversation
|
@reznikmm or @simonjwright, any ideas or suggestions about the error starting here? It looks like some kind of dynamic library loading failure. This is for an |
|
I haven't seen this error before 😞 Shall we add |
eea9346 to
9ddce90
Compare
|
It's strange because it isn't happening in the |
Perhaps that the original gnat used to build the failing alr is not available in this instance. But this is a stab in the dark. |
That’s almost certainly the reason. If I build with The paths used to interpret There are several puzzling things. The outputs of so what is it we’re doing differently in the x86_64 nightly from the other 3? And, why do the Alire compilers both include Using whereas mine outputs It’s not that the Alire compiler includes the xcode_15_fix. Also, my GCC 12 & 13 builds produce the short version! I think that |
I've verified the problem is happening at the nightly workflow, and adding that option indeed works. Thanks! |
|
Thanks for the analysis, Simon, I missed your reply while I was trying things in the nightly build.
At this time what I can say is that we build from different workflows, and in particular for macOS there were some custom actions introduced by Maxim to support aarch64. I'm on the process of removing those, since we have now aarch64 toolchains in the index, and maybe that will homogenize things. In any case, explicitly requesting static linking to libgcc seems to have worked. I'm unsure about secondary effects, as the description of that switch contains worrying comments about exception handling. But all of our tests pass, so... Thanks for your help with this as the moment we enter linker territory I become stupefied. |
b214af1 to
77947b9
Compare
|
Thanks for your help, Maxim, Simon; with this one we have the aarch64 builds in the v4 branch. |
No description provided.