-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unable to build against musl #324
Comments
See |
Emulating the approach there, I get a similar macro error:
|
Oh. I can't read. Ran out of memory. Ha! |
Okay, now I think I hit an actual failure on master
|
That's a curious crash, can you run with |
Switched to a Dockerfile for testing, so it should be easy for you to reproduce if you like.
This includes your tests, a few of which fail:
If I comment out the test lines and let it keep building I get:
|
That's another out-of-memory error. |
Now that I'm more awake - the failing tests may be linked to the issue, plus that OOM is for a massive byte count (~40GB) |
I was able to get a successful build from the following debian dockerfile with 15G of memory assigned to the building VM:
However, building with the last alpine dockerfile I posted earlier (which is almost identical to the debian one) I still get the same build error in the same spot, even with 30GB of memory available. Going to give it more ram and try again. |
It shouldn't need that much. I've installed docker and reproduced the error, although it seems inconsistent. |
Output from doing a manual run to debug/diagnose. Seems like there's some nondeterministic behavior in the generated code.
|
This might be an error in the |
I have the VM assigned 20 cores, which might explain the high ram usage due to the number of jobs. Increasing ram to 45G and I am at least able to get through to the error without obvious memory allocation failures:
As for your theory about -musl target, I mistakenly had -musl set in my debian dockerfile above, and that built just fine. That would indicate to me that there is a hard expectation on the system libc being glibc somewhere. Everything in alpine and the distro I am working on is linked against musl, so clobbering the global default libc paths would break things. Do you know of a global way to specify an alternate libc search path that will work with your whole build chain so I can feed it a one-off built glibc? It would mean of course the resulting rustc 1.54 binary will be linked against glibc, though it should in theory be able to produce newer versions of rust linked against musl normally, I think. |
Yeah, just did a build in alpine with "RUSTC_TARGET=x86_64-unknown-linux-gnu" and same issue:
Something is incompatible with the system libc being musl. Am going to try packaging glibc then try to build only mrustc C++ binaries against it and see if the rest holds with musl. |
Yes. libstd is being told that the system libc is glibc (see |
Ah! That makes sense. I'll try adjusting those and see if I can get it working, then submit a PR if so. |
If you get it working, a PR would be appreciated. |
Thanks for the merge. Was able to build with shared llvm13 using the LLVM_CONFIG variable. When I went to actually use the rustc and cargo to build the next version of rust however, I realized I had not actually built libstd and friends in run_rustc yet, so what we merged is just a partial solution. Run_rustc failed pretty early due to the hardcoding of x86_64-unknown-gnu in run_rustc/Makefile. I corrected this with the following patch:
This allowed me to get a lot further, but a new build failure which seems like some sort of path issue still, though I can't see any more hadcoded -gnu references. Been debugging this a while so another set of eyes would be welcome, as I don't fully understand all the custom stage paths and when they are used yet.
|
Attaching a full build log of the above. |
|
@thepowersgang Am I doing something in an unexpected order to cause that to happen? I am having a hard time finding much information on how make makes pruning decisions. |
Went back to Alpine as a better understood control case using the following dockerfile:
Failed in a way I have never seen rust fail:
|
Possibly relevant issue: rust-cross/rust-musl-cross#37 |
Okay! With a few hacks in my branch (that will take some work to clean-up so as not to break other targets) I was able to get run_rustc to run to completion with musl, and get hello_world. The full mrustc docker bootstrap build setup here generates a rust 1.54 container. I then try to use that container to bootstrap rust 1.55 as follows:
This however results in some build errors I don't understand as I have the full prefix from mrustc present:
Any suggestions welcome! |
Did you look at |
Just made some adjustments to that script for my env and made it much further at least. On closer inspection this appears to be because I have rustlib at /lib/rustlib instead of /usr/lib/rustlib. Always something dumb like pathing that I overlook! Anyway, this died 3 minutes in like this. On to the next level of debugging.
|
LLVM failing to compile it seems
|
Managed to get a successful build of 1.55 on x86_64-unknown-linux-musl re-using the shared llvm13 which was my ultimate goal. Should be a loop from here to get myself up to current rust! Want to get my run_rustc changes cleaned up and put in a PR for you, so we can close out this issue. I have some "HACK" comments in there where I have to copy system libraries into your prefix paths manually in order to get the builds to complete. Is there a more sane way to append to the library search paths in your setup so I don't have to copy all the system files like libc over? |
|
Unable to bootstrap 1.54 from musl or glibc based linux distributions.
musl (alpine)
Repeated with master, and v0.10.1
glibc (debian)
Repeated with master, and v0.10.1
The text was updated successfully, but these errors were encountered: