Closed JamesGuthrie closed 10 months ago
Seems reasonable - @msepga @seanlinsley any concerns with adding that?
@JamesGuthrie As an alternate approach to special casing musl, I'm curious if changing to the cc
crate would also fix the issue addressed here?
If you could give #39 a try, that changes to using the cc
crate instead of the Makefile (see https://github.com/pganalyze/pg_query.rs/pull/39/commits/f32528e5895813a07b84874accedf72753624355)
@lfittl Thanks for your work on this issue. I've tested building my code for the x86_64-unknown-linux-musl
target against the windows-support
branch (#39), and I was able to get it to work. I did need to override the CC
env var:
CC=musl-gcc cargo build --release --target x86_64-unknown-linux-musl
I will close this PR in preference of #39 or https://github.com/pganalyze/pg_query.rs/commit/f32528e5895813a07b84874accedf72753624355.
The
libpg_query.a
static archive fails to link during a release build for musl targets with errors like: "undefined reference to `_longjmp_chk'".This appears to be caused by the fact that the static archive is compiled with the default toolchain, and so has references to symbols provided by glibc (but not musl libc).
This change switches to use the
musl-gcc
wrapper asCC
when the target triple ends with-musl
.