Closed opensourcegeek closed 7 years ago
What happens if you run this manually from the command line?:
"musl-g++" "-O0" "-ffunction-sections" "-fdata-sections" "-fPIC" "-g" "-m32" "-static" "-march=i686" "-Wl,-melf_i386" "-I" "include" "-std=c++0x" "-fdata-sections" "-ffunction-sections" "-pedantic" "-pedantic-errors" "-Wall" "-Werror" "-Wextra" "-Wcast-align" "-Wcast-qual" "-Wenum-compare" "-Wfloat-equal" "-Wformat=2" "-Winline" "-Winvalid-pch" "-Wmissing-declarations" "-Wmissing-field-initializers" "-Wmissing-include-dirs" "-Wredundant-decls" "-Wshadow" "-Wsign-compare" "-Wundef" "-Wuninitialized" "-Wwrite-strings" "-fno-strict-aliasing" "-fvisibility=hidden" "-Wno-cast-align" "-fstack-protector" "-g3" "-U_FORTIFY_SOURCE" "-D_XOPEN_SOURCE=700" "-c" "-o/root/bigquery/target/i686-unknown-linux-musl/debug/build/ring-6c8441ff98710207/out/bn_test.o" "crypto/bn/bn_test.cc"
In particular, is it not finding musl-g++
, or is it not finding bn_test.cc or one of the directories?
Ah musl-g++ cannot be found! Quick googling doesn't bring up any musl-g++ compilers either.
musl-g++ -O0 -ffunction-sections -fdata-sections -fPIC -g -m32 -static -march=i686 -Wl,-melf_i386 -I include -std=c++0x -fdata-sections -ffunction-sections -pedantic -pedantic-errors -Wall -Werror -Wextra -Wcast-align -Wcast-qual -Wenum-compare -Wfloat-equal -Wformat=2 -Winline -Winvalid-pch -Wmissing-declarations -Wmissing-field-initializers -Wmissing-include-dirs -Wredundant-decls -Wshadow -Wsign-compare -Wundef -Wuninitialized -Wwrite-strings -fno-strict-aliasing -fvisibility=hidden -Wno-cast-align -fstack-protector -g3 -U_FORTIFY_SOURCE -D_XOPEN_SOURCE=700 -c -o/root/rustls/target/i686-unknown-linux-musl/debug/build/ring-6c8441ff98710207/out/bn_test.o crypto/bn/bn_test.cc
**musl-g++: command not found**
Thanks! It seems similar to https://github.com/rust-lang/cargo/issues/3359.
FYI, I probably won't do anything about this except work on https://github.com/briansmith/ring/issues/477 to make it a non-issue. But I am open to accepting PRs to work around it in some way in the interim.
I might have to ditch yup-oauth2 library to talk to Google bigquery (which depends on hyper-rustls, which depends on rustls which in turn depends on ring@0.7) and write my own wrapper to do HTTPS calls. This whole tls/ssl area is one place I get bitten with rust all the time, I hope it gets better in future! Sorry for not being able to better help you in this case.
Reopening, because I think it is a valid issue, and maybe somebody wants to provide a workaround before #477 gets fixed.
I'm not sure this is a generic solution, but I've been able to produce a working static binary for a project that uses yup-oauth2 and hyper-rustls by short-circuiting musl-g++
to g++
. Copying the musl-gcc
script to use g++
also results in a working binary for my application.
@rsdy I haven't seen static binaries(no library dependencies on target platform) being produced using gcc/g++ that uses glibc at least. I could be wrong though, please do share steps taken
For now I've downgraded to yup-oauth2=1.0.1 and it works as it depends on hyper 0.9.13 which supports SSL connections using openssl (openssl-sys) and I've got it building for musl using docker https://github.com/opensourcegeek/muslrust-32.
It was also my fault as I was depending on yup-outh2="1.0.1" but cargo was pulling 1.0.5 which happens to depend on more recent hyper 0.10 which doesn't support SSL connections (you need external crates to do that). Changing it to "=1.0.1" helped to pin down dependency correctly.
On a more general note, a lot of libraries are still pre 1.0, so they make breaking changes(probably without realising) with just a minor version bump. In this case hyper drops SSL support completely in 0.10 and yup-oauth2 upgraded hyper dependency but didn't bump even minor version. It is understandable, so I've to be more cautious when I add dependencies.
https://gist.github.com/rsdy/1a3b418f45800afa738b6a0bbe08f7d3 This Dockerfile illustrates the solution.
https://github.com/briansmith/ring/issues/713#issuecomment-717654176 describes the current state of musl support. Marking this as a duplicate of #713.
I'm not sure what is going wrong here, I'm trying to build for i686-unknown-linux-musl target and it fails, any ideas please? Below is verbose output of build,