You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I've been trying to build rustc_codegen_gcc for m68k-unknown-none-elf (basically, bare-metal m68k with only libcore) in a Docker container. But, I've hit a dead-end: whatever I try to do in the Dockerfile, the image compilation never progresses past trying to build the sysroot because rustc_codegen_gcc cannot load the libgccjit.so file, even though it's right there (found by the find command) and was just built before building rustc_codegen_gcc
I was wondering if you could help me fix this. It would mean a lot to me
Hi.
Your CI logs shows the paths it looks for the lib:
#20 35.21 Could not load libgccjit.so. Attempted paths: [
#20 35.21 "/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so",
#20 35.21 "/root/.rustup/toolchains/nightly-2026-03-26-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so",
#20 35.21 ]
Could you please check whether the step building the sysroot copied your libgccjit.so file in the first location (/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so)?
If not, could you try using find to see whether it was copied elsewhere?
A next step would be to add some logging around here to check where it was copied.
Hi. Your CI logs shows the paths it looks for the lib:
#20 35.21 Could not load libgccjit.so. Attempted paths: [
#20 35.21 "/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so",
#20 35.21 "/root/.rustup/toolchains/nightly-2026-03-26-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so",
#20 35.21 ]
Could you please check whether the step building the sysroot copied your libgccjit.so file in the first location (/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so)? If not, could you try using find to see whether it was copied elsewhere?
A next step would be to add some logging around here to check where it was copied.
I modified the Dockerfile to check if those paths existed. Due to a Docker quirk I failed to account for (compilation stops after the first command that returns a non-zero error code), it only checked the first path.
32.79 ls: cannot access '/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so': No such file or directory
So the build system didn't create the symlink to libgccjit.so in the sysroot, I'll have to restart the build again to check where it actually symlinked the file
If you follow the instructions without Docker, you are able to get further?
I would still suggest you change the line I linked above so you see whether the symlink is created before building the sysroot and where it is created.
If you follow the instructions without Docker, you are able to get further?
I would still suggest you change the line I linked above so you see whether the symlink is created before building the sysroot and where it is created.
Sorry for not responding, I spent a long time building this manually and modified the build system to print where it symlinked:
Creating symlink to "/gcc/lib/libgccjit.so" at: "build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k-unknown-none-elf/libgccjit.so"
I did a temporary fix by symlinking the m68k-unknown-none-elf directory to m68k
Activity
antoyo commentedon Apr 28, 2026
Hi.
Your CI logs shows the paths it looks for the lib:
Could you please check whether the step building the sysroot copied your
libgccjit.sofile in the first location (/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so)?If not, could you try using
findto see whether it was copied elsewhere?A next step would be to add some logging around here to check where it was copied.
You might already know, but just in case we have a CI workflow to build cg_gcc for m68k.
techmetx11 commentedon Apr 28, 2026
I modified the Dockerfile to check if those paths existed. Due to a Docker quirk I failed to account for (compilation stops after the first command that returns a non-zero error code), it only checked the first path.
32.79 ls: cannot access '/opt/rustc_codegen_gcc/build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k/libgccjit.so': No such file or directorySo the build system didn't create the symlink to libgccjit.so in the sysroot, I'll have to restart the build again to check where it actually symlinked the file
antoyo commentedon Apr 28, 2026
Just to make sure, are you attempting to build a cross-compiler or a native rustc for m68k?
techmetx11 commentedon Apr 28, 2026
Cross-compiler for m68k.
antoyo commentedon Apr 28, 2026
If you follow the instructions without Docker, you are able to get further?
I would still suggest you change the line I linked above so you see whether the symlink is created before building the sysroot and where it is created.
techmetx11 commentedon Apr 28, 2026
Sorry for not responding, I spent a long time building this manually and modified the build system to print where it symlinked:
Creating symlink to "/gcc/lib/libgccjit.so" at: "build/build_sysroot/sysroot/lib/rustlib/x86_64-unknown-linux-gnu/codegen-backends/lib/m68k-unknown-none-elf/libgccjit.so"I did a temporary fix by symlinking the
m68k-unknown-none-elfdirectory tom68kantoyo commentedon Apr 28, 2026
It seems it's a bug on the side of cg_gcc around here.
It seems to use
m68kinstead ofm68k-unknown-none-elf.I'll try to fix this, but it might take a few days.
Are you currently blocked on this?
techmetx11 commentedon Apr 29, 2026
Not really, I can modify my Dockerfile to work around this issue. But it might be more difficult doing it manually outside of Docker