Bootstrap config: libgccjit libs dir

[antoyo]

r? @Kobzol

[rustbot]

This PR changes how GCC is built. Consider updating src/bootstrap/download-ci-gcc-stamp.

This PR modifies src/bootstrap/src/core/config.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

[rustbot]

Kobzol is not on the review rotation at the moment.
They may take a while to respond.

[antoyo]

@Kobzol: I'm sending this PR to gather some feedback from you or others.

How can I add tests for this new bootstrap config?
Where should I document this new config?

[bors]

☔ The latest upstream changes (presumably #149348) made this pull request unmergeable. Please resolve the merge conflicts.

[Kobzol]

I will focus on #149426 first, as I think that we should first deal with the compiler/cg_gcc side of things, before we go modify bootstrap.

[Kobzol]

This makes sense, although the implementation needs some changes. I'd be happy to play with this if you don't want to deal with doing these bootstrap changes.

View changes since this review

[bors]

☔ The latest upstream changes (presumably #149426) made this pull request unmergeable. Please resolve the merge conflicts.

[Kobzol]

I refactored the code a bit to more explicitly model that we have multiple target libgccjit dylibs per host, and also to enable both downloading from CI and using prebuilt libgccjit.so files (so that people don't also have to build their x64 libgccjit.so from scratch). Please let me know if it makes sense to you.

[antoyo]

Please let me know if it makes sense to you.

This commit makes sense to me.
For the other commit, I do not understand bootstrap enough to understand what's happening here. Would that commit help keep the m68k libgccjit.so file that was deleted? Do you want me to try to cross-compile rustc locally with that commit?

[Kobzol]

Do you want me to try to cross-compile rustc locally with that commit?

If you already have it prepared, yeah, you could try it. Although CI failed, so maybe there's something else wrong.

[antoyo]

If you already have it prepared, yeah, you could try it. Although CI failed, so maybe there's something else wrong.

Good. I try that right away.

[antoyo]

If you already have it prepared, yeah, you could try it. Although CI failed, so maybe there's something else wrong.

The command finished running and the issue with the m68k libgccjit.so file being deleted still seems there. Any ideas of how to fix this? Do the steps I posted above give you any hint?

[Kobzol]

I suspect I know where is the issue. bootstrap hacks around this for LLVM, but I don't like how it is done (I want to refactor how LLVM is handled in bootstrap, as it's super messy right now, but it's very hard).

In that case, I would actually suggest to sidestep this issue entirely and use a different directory structure: <sysroot>/lib/rustlib/<host-target>/codegen-backends/lib/<target>/libgccjit.so. This I think also makes it clearer that cg_gcc is actually invoked on <host-target>, and it will use libraries from its lib subdirectory, rather than from completely different directories in <sysroot>/lib/rustlib/....

This will run into an issue with Rustup later, but we would have the exact same issue even with the current layout, so it doesn't really matter.

What do you think?

[antoyo]

What do you think?

I'm OK with this directory structure.
But since this is still in rustlib, won't that get deleted too?

[Kobzol]

I certainly hope not 😆 Bootstrap should only be deleting rustlib/<target>/lib, I think. If not, then I misunderstood the issue.

[antoyo]

I certainly hope not 😆 Bootstrap should only be deleting rustlib/<target>/lib, I think. If not, then I misunderstood the issue.

Ok. I'll try this new directory structure locally to see if that works. If so, I'll push it here.

[antoyo]

I remember @bjorn3 had some concerns about a similar directory structure.
@bjorn3: Could you please confirm that this won't result in having multiple directories in /usr/lib with different target triples when doing a global install?

[antoyo]

There seems to be one issue: the native m68k libgccjit.so library is not copied in the sysroot. Instead, it takes a native x86 libgccjit.so:

rust/build/m68k-unknown-linux-gnu/stage2/lib/rustlib/m68k-unknown-linux-gnu/codegen-backends/lib/m68k-unknown-linux-gnu/libgccjit.so:       ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7fb2bb8bf0436221a668bcd67d6042c067463bd6, with debug_info, not stripped

@Kobzol: Any idea what could be wrong here?

Edit: Could it be the step "Uplifting library (stage1:x86_64-unknown-linux-gnu -> stage2:m68k-unknown-linux-gnu)" that does that?

[antoyo]

My investigation leads me to believe that we don't fill properly dylibs here.

My understanding is that for a specific stage, we need:

• target of the built rustc (usually x86-64 for stage1, but here is m68k for stage2) -> target of the build rustc (here would be x86-64 -> x86-64 for stage1 and m68k -> m68k for stage2).
• and possibly target of the build rustc (usually x86-64 for stage1) -> other targets configured (here is m68k) (here would be x86-64 -> m68k for stage1).

But that code seems to consider the host target (the one used to build the rustc) instead.