On Sat, Nov 09, 2024 at 10:34:15AM -0700, Simon Glass wrote: > Hi Tom, > > On Tue, 5 Nov 2024 at 10:03, Simon Glass <s...@chromium.org> wrote: > > > > Hi Tom, > > > > On Tue, 5 Nov 2024 at 09:54, Tom Rini <tr...@konsulko.com> wrote: > > > > > > A long time ago, we had to use "i386" and "x86_64" toolchains for our > > > x86 platforms, depending on the target. We then moved to being able to > > > use the single "i386" toolchain to support all x86 platforms. At the > > > same time, we had been building sandbox with our "x86_64" toolchain in > > > CI. When x86 switched to being able to use a single toolchain we did not > > > update our CI buildman file to match. Do this now as we want to ensure > > > that sandbox is built with the same compiler version the rest of our > > > platforms are and not the host one. > > > > > > Signed-off-by: Tom Rini <tr...@konsulko.com> > > > --- > > > Cc: Simon Glass <s...@chromium.org> > > > > > > I'm posting this as an RFC to start the discussion as when I mentioned > > > this to Simon on IRC, he was very much not in agreement. > > > > > > My main argument is this, sandbox needs to use the same toolchain that > > > we compile (virtually) all other platforms with as one of the points is > > > to be able to catch warnings and compiler behavior changes as soon as > > > possible in our CI. And just like how developers can use > > > distribution-provided toolchains today, nothing changes in that regard, > > > we only make CI be more consistent now. > > > > OK, that makes some sense to me, actually. It isn't the toolchain that > > people will be using, but catching things earlier seems good. > > > > The main concern I have is that we are not testing sandbox on the > > toolchain that everyone will be using. But I haven't noticed failures > > in CI which I cannot repeat locally, so we can cross that bridge when > > we come to it. > > > > Reviewed-by: Simon Glass <s...@chromium.org> > > This doesn't seem to work, for a few reasons: > > 1. Buildman doesn't support setting HOSTCC and CC unless using -O to > override the toolchain (so the setting in this patch has no effect)
That shouldn't matter tho. > 2. Using the toolchains from kernel.org gives this error: > > NO_LTO=1 make O=/tmp/b/sandbox defconfig all > HOSTCC=/home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc > CC=/home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/x86_64-linux-x86_64-linux-gcc > -j30 -s > /home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/../lib/gcc/x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld: > cannot find crt1.o: No such file or directory > /home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/../lib/gcc/x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld: > cannot find crti.o: No such file or directory > /home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/../lib/gcc/x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld: > cannot find -lc: No such file or directory > /home/sglass/.buildman-toolchains/gcc-13.2.0-nolibc/x86_64-linux/bin/../lib/gcc/x86_64-linux/13.2.0/../../../../x86_64-linux/bin/ld: > cannot find crtn.o: No such file or directory > collect2: error: ld returned 1 exit status > make[3]: *** [scripts/Makefile.host:95: scripts/basic/fixdep] Error 1 > make[2]: *** > [/scratch/sglass/cosarm/src/third_party/u-boot/files/Makefile:503: > scripts_basic] Error 2 > make[1]: *** > [/scratch/sglass/cosarm/src/third_party/u-boot/files/Makefile:568: > __build_one_by_one] Error 2 > make: *** [Makefile:177: sub-make] Error 2 So yeah, here's the real problem. In the past the kernel.org toolchain was (unintentionally I believe) good enough to make user-space programs too. That's not the case now, and sandbox is really a userspace program and not a bare-metal program. So really the current line from the Dockerfile just needs to be removed. -- Tom
signature.asc
Description: PGP signature
