-
Notifications
You must be signed in to change notification settings - Fork 547
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
[WIP] add ROOT #7666
[WIP] add ROOT #7666
Conversation
Co-authored-by: Mosè Giordano <[email protected]>
we could try to build with
|
https://buildkite.com/julialang/yggdrasil/builds/6574#018bc96b-a76b-411b-b95e-a47be7b32c5b/6-5146 but then is this some weird stuff ROOT is doing that re-run CMake with another set of configs? |
Sounds like it's building LLVM? We should be using our own LLVM. |
is |
Not really, linking to LLVM is complicated, see Enzyme recipe |
It's using |
where can I find the llvm-config from prefix? currently tried:
|
looks like I need
but that path is wrong |
@Moelf, you need to use clang code from ROOT, which differs from vanilla one in order to support Cling: see here. In these conditions, I'm not sure you can use your own LLVM version, considering that standard build of clang is done by putting clang code in the LLVM source tree and build both together: see https://clang.llvm.org/get_started.html. |
well, wtf. 😂 I think we can technically build without Cling though, maybe we should do that |
Say we go back to use its own LLVM, how do I by pass that calling CMake within make ... I think it's not respecting our flags in that case Maybe I will study Arch Linux recipe's patches more closely |
I think it's easier to follow the standard ROOT build instructions. ROOT is also distributed as Conda, Snap, and docker packages. You may have a look at how these packages are built. |
and there are shit load of patches as well
|
I now suspect it's because the
is there a way to verify this theory? |
https://buildkite.com/julialang/yggdrasil/builds/6619#018bcea7-4b07-476a-9c1a-fccfb081f038/6-1790 removing TOOLCHAIN files doesn't work but got us much further. |
If you need to build LLVM then i would look at the LLVM build we have to see what things need to be done |
Do we have |
Note that we're trying to do a cross-compilation, so the host and the target platforms are in general strictly different. So if you ask "Do we have |
@giordano for time being I'm trying using the same platform for the target and host, which does not exclude possible issues with paths. After this, I will probably need your input to define a strategy. E.g., make a package for @vgvassilev stdc++ is installed. Here is the output with
|
The same version of libstdc++ needs to be installed when compiling and when running. I am not aware that ROOT supports cross-compilation. That might be a problem... |
now I wonder if ROOT can build on Alpine linux to begin with, ignore cross-compilation for a second, we should be able to build on Alpine linux to generic x86 binary and run on any linux x86, or not? |
@Moelf ROOT builds on Alpine. @vgvassilev There several copies of stdc++ libraries, all 6.0 and only the patch number differ. The version that must be the same are the one rootcling is linked to when we run it (output of |
@giordano is it possible in the container to |
I don't think so because you'd be missing the entire operating system, can't do much with just what you find under |
I did not manage to solve the issue. The crash of I suspected some consistency issue in the built LLVM libraries and |
We've seen musl blow up with LLVM in interesting ways. One option would be to use x86-gnu instead of musl. |
Thanks @gbaraldi for the suggestion. The idea of starting with musl was the need to run a build product during the build process, but I was also thinking of another approach: build it for glibc and use the possibility to run glibc-based executable on Alpine. I have made some progress, thanks to inputs of a colleague with experience with building ROOT for Alpine. Apparently for this the So with the build configuration
I expect it is link to the
The first one is excluded from The second and last one are included as I have also tried the Philippe. |
update: build for x86_64-linux-gnu (glibc instead of musl) and use of Alpine |
I've updated the build script. It compiles for x86 with musl. It doesn't with glibc. I failed to instruct the @vgvassilev and @peremato could you have a look ? Command to run the build:
It will open a shell in the Alpine container on failure. The file For a build with musl, append Philippe. |
The git history of this branch is now quite messed up, with many unrelated changes showing up in the diff |
Fixed. |
Ok, the diff is now resolved, thanks. Is there a way not to see 396 commits in the history though? GitHub even refuses to show most of them 🙂 |
. Works for x86_64-linux-musl, but of little use, due to the general dependency library loard issue for .jll packages with musl . Fails for x86_64-linux-gnu: misses to instruct the cross-compiled rootcling_stage1 to use the header files of the sysroot of the target host.
history should also be fixed now. |
With above change ac99958, the
followed by a similar error for the function I couldn't get what It looks like we mix up two versions of the The
System header directory path list is set before running
It copies the path from the cross-compiler. |
My understanding is that the strategy for cross-compiling is:
|
It does compile for |
Continued in a new PR #9300 |
@grasph this is the first step to making ROOT.jl usable again.
I've been using https://archlinux.org/packages/extra/x86_64/root/ as a reference for dependency and make dependency
Currently: