Closed jerbob92 closed 1 year ago
Hi @jerbob92,
I wonder if it could come from e530f1eb92b30e414e787a2adfa6f95e10a7b9d0. Unfortunately, I could not find the reason for this change; I wish I documented it somewhere.
Could you try with use_custom_libcxx
set to true
?
Best regards, Benoit
@bblanchon just tried and you can't compile with use_custom_libcxx=true, it results in a bunch of errors while compiling libc++ and the following warning:
WARNING at build arg file (use "gn args <out_dir>" to edit):11:22: Build argument has no effect.
use_allocator_shim = false
^----
The variable "use_allocator_shim" was set as a build argument
but never appeared in a declare_args() block in any buildfile.
I tried to build branch chromium/5092, but for some reason that didn't work at all, so I can't validate if it worked before the change of use_custom_libcxx.
I tried to use the latest libc++ but that resulted in a bunch more/different errors so I wonder if it's supposed to build with musl, it does have the options _LIBCPP_HAS_MUSL_LIBC
and LIBCXX_HAS_MUSL_LIBC
I think use_custom_libcxx should be kept to false, if you put it to true it will try to compile libc++ (from LLVM) with musl, which seems problematic. This should not be necessary because the cross-compile kit from musl comes with a C++ compiler. I have not found out yet where these symbols are coming from though...
Possible fix in #130
@bblanchon We do have to check if this gives the expected result though. I'm not completely sure we're not just embedding the host libraries statically now :thinking:
Hi,
I'm trying to use the musl build in a Docker image, but when I want to compile against the musl binary, I get the following errors:
This makes me wonder if the musl build is actually a musl build, looking at the glibc references.