Closed izderadicka closed 5 years ago
I'm sorry to hear about this problem!
Unfortunately, you should probably assume that fixing a complicated C or C++ library to build and work with a musl-libc
cross compiler can be very tricky. I usually expect to spend about 4 hours debugging problems like these whenever I add a new C library, and that's with lots of web searches for similar problems. Basically, static linking is a bit of a hack, and not all libraries and toolchains support it. You can either push through and find a solution, or you can use regular dynamic linking. I wish I had a better answer for you. :-(
I've had a lot of success with statically linking C++ libs when I ran my build inside a alpine container with an explicit target for alpine musl.
For example: https://github.com/superfly/fly.rs/blob/master/Dockerfile
Hi,
I'm trying to build static binary, which depends on taglib, which is C++ library with C bindings. I use this rust crate, which binds this library - https://github.com/ebassi/taglib-rust.
After bit of playing around I ended up with link failure, where only two symbols are missing
__dso_handle
and__sprintf_chk
- first one seems to be generic problem of static linking of C++ library - as refered here https://github.com/rust-lang/rust/issues/36710#issuecomment-364623950 (with some possible workaround), for second symbol I'm not sure - it looks like some incompatibility between glibc and musl libc? Musl faq says "The existing libstdc++ is actually compatible with musl in most cases and could be used by copying it into the musl library path".Here are steps I've done to compile (using this image):
And got this error:
My question is if somebody has experiences with using C++ library in static build, if I'm doing something wrong or if there are any recommendation how to process, I'm not much expert on c/c++, I saw that possibily of custom build script, but I guess it'll still not solve the problem with second symbol
__sprintf_chk
.Thanks