Replies: 2 comments 3 replies
-
Hi there
You might already know this, but this config is not specifying an arm64 machine. This runner is on x86_64, Github hasn't released arm64 runners yet(!). So this is cross-compiling arm64 from x86_64.
An issue here is that you're not detecting the right case in setup.py. Because we're running this build on x86_64, the But I suspect the issue is that your dependency, libpg_query, isn't cross-compiling well. cibuildwheel does set the But it's going to be easier to do it native. CirrusCI does offer (limited) free arm64 CI for open source, perhaps you can try that. |
Beta Was this translation helpful? Give feedback.
-
An update before closing this, for posterity. First thing I tried has been changing the way the extension gets compiled: instead of building the I eventually switched to the new Thanks again Joe for your hints! |
Beta Was this translation helpful? Give feedback.
-
Hi, I'm seeking some cue about a linkage problem I do not understand.
I'm the author of pglast: it basically builds some facilities on top of a static library containing the PostgreSQL parser.
Recently I added silicon macs to the build matrix. Since I do not own that kind of machine, and that I disabled CI tests for that combo, it went unnoticed that, although the process completed successfully, the wheel contains a broken shared object.
A friend lent me an hour of his M3 machine, and I found that, apparently, the ARM64
pglast/parser.cpython-311-darwin.so
was not properly linked against the staticlibpg_query.a
, as even the size suggests: the Intel one is much bigger, and inspecting them withnm
it actually contains all the expected_pg_query__XYZ
concrete symbols, missing in the ARM64 one.I looked around and tried a different approach, but even that does not seem to solve the problem.
I wonder if some kind soul around here, more expert than me on that architecture, may shed some light on the problem?
Thanks in advance for any hint!
Beta Was this translation helpful? Give feedback.
All reactions