System library build of Julia master fails on ARM macOS #44435
Comments
|
(I'm documenting my own tries at understanding the build logic here, to help fix the issue…) I am missing something in the logic. Why is Line 207 in e84b06c And given that libquadmath is not present on all targets, how is this expected to work? Line 211 in ea1b9cf |
macOS ARM is not stable on the 1.7 branch. Even if you get it building, we would not recommend shipping it to users. |
@staticfloat - Are we using .2 for our CSL? Maybe we have an older version of the GCC branch? |
ViralBShah
added
the
system:apple silicon
https://github.com/JuliaPackaging/Yggdrasil/blob/147ed4d8c7f29dd677ae73bb33cdf237736609c6/0_RootFS/gcc_common.jl#L139. The commit iains/gcc-darwin-arm64@ccc57f4 is from November 2020. |
That explains it. It's an old, experimental version of the toolchain, and the dylib version was changed in later development. That still does not explain why |
If we wanted to update our toolchain, which branch we should use? The README seems to suggest to use |
The current branch is Right now the latest rebase is at |
|
Even if we bypass the libgcc shared version number issue, we get another error, even using the master branch: Do you have any idea what could cause this? I'm not seeing this in any of the reports here… |
|
As mentioned above, Julia on aarch64 macOS has a known serious bug (namely #41440) which causes very frequent segmentation faults. That bug has been fixed as part of the upgrade to LLVM 13 and it'll be included in the next minor version v1.8.0, but it can't be backported to the v1.7 series. This means that even if you manage to build Julia v1.7 for that platform you'll have many other runtime issues. That said, if you're building with system libraries with versions different from those tested in the official binaries, it isn't unlikely you'll run into fresh new bugs which no one else has ever faced before. |
DilumAluthge
changed the title
|
@DilumAluthge the bug reported in the title still exists on master @giordano I'm sorry, I should have added to the bootstrap error that we also see that one on latest master sources. How can we debug it? |
DilumAluthge
changed the title
I don't know how to debug the error during bootstrap, but I'm wondering what version of LLVM are you using? |
LLVM 13.0.1 |
|
OK, redoing the build on today's master, with this PR applied #44484 The command-line is: I'll keep the build intact, can someone please let me know how to obtain a backtrace, or debug this, to provide more information? |
|
The soversion of |
|
Thanks @giordano
|
|
Good catch, thanks! However in |
|
In It's hard for me to have a clear global view of the build system, but we have found in Homebrew builds that it is important to have |
|
Ok, I was confused because there wasn't a Lines 579 to 581 in 487757b |
|
@fxcoudert for the bootstrap issue, this is the makefile rule that is failing: Lines 60 to 64 in 3bcab39 base/)
In particular, the offending line in the bootstrap process is julia/base/compiler/bootstrap.jl Line 8 in 3bcab39 Int32, I don't see an Int32 there.
|
|
@giordano yes I've run that
I don't think it's that one, because I can comment it out (and all calls to |
|
Uhm, that line was mention in the error you posted at #44435 (comment). |
|
I don't know Julia, but it mentioned line 10, not 8. |
|
I read |
|
Wait, I think there is a mix up here. What branch are you looking at? |
|
I'm running |
|
In lldb/gdb the function name is |
|
Sadly, a lot of frames have no debug info 😢 |
For a debug build you need to use Note that to save on disk this and the other options you can create the file override JULIA_BUILD_MODE=debug |
|
New backtrace, with |
|
The error is: There is no julia/base/compiler/bootstrap.jl Line 10 in 80346c1 Is there no way to ask Julia to tell me what |
For general usage there are different tools (see repositories in the JuliaDebug organisation, for example |
Do you know who would? I would literally run anything to understand what happens at this stage. |
|
Inside of |
|
@staticfloat thanks. I'm not seeing much more info: … and all the way up to: |
|
Ideas for further progress:
You can scatter |
|
Should have thought of It crashes on the first call of julia/base/compiler/bootstrap.jl Line 47 in 8076517 I can print the arguments: I added print statements to the function I reach 5, but not 6, so the issue is apparently in and there it gets weird, because:
So |
|
julia/base/compiler/abstractinterpretation.jl Line 298 in 8076517
|
|
Yes, type inference will call It's curious to me that we actually pass through Do you get anything useful out of |
|
I tried stacktrace but: But after more than an hour of printing stuff, I've found the trace myself. It's: called from (see above): Line 945 in 8076517 I now see this The arguments to the call are: |
|
The wrong parameter here (I think) is |
This kind of error often happens when there is an LLVM miscompilation. Do you have all our patches applied? |
|
@Keno We (Homebrew) are compiling against LLVM 13.0.1. We're not seeing this issue on Intel, only ARM, so if it's a LLVM issue, it's ARM-specific. Where can I find the list of patches against LLVM 13.0.1 that you recommend? There's no LLVM-related patch in https://github.com/JuliaLang/julia/tree/master/deps/patches |
|
https://github.com/JuliaLang/llvm-project/commits/julia-release/13.x is the list of patches. If I had to guess, I think you may be seeing https://bugs.llvm.org/show_bug.cgi?id=49357 (which we disable in JuliaLang/llvm-project@7627d61). That said, do note that our patch set is not in general appropriate for inclusion in a general LLVM copy provided for other projects (unitl those patches are upstreamed) and we recommend vendoring a private copy of LLVM for use by Julia. |
I know, every project wants their own copy of all dependencies, but for a complete distro things grow out of hand quickly. So far we have shipped Julia build against released LLVM, but I'll consider the options available… |
|
Closing this, various parts have been reported separately and fixed in different PRs. |
We're trying to build Julia 1.7.2 in Homebrew (Homebrew/homebrew-core#96194) but it has several failures. The first one is this:
On ARM macOS, using the GCC branch from Iain Sandoe (https://github.com/iains/gcc-darwin-arm64), the name for the
libgcc_slibrary should belibgcc_s.1.1.dylib: version is1.1, not1, and not2, as is in master:julia/Make.inc
Line 1477 in fb4118a
The text was updated successfully, but these errors were encountered: