On Fri, Aug 23, 2024 at 04:08:28PM +0800, Yunqiang Su wrote: > I struggled with the build system, and I know the real problem:
Thanks for chiming in! > 1. linux-libc-dev-ARCH-cross is useful, for some case if we maintain an cross > toolchain of a port > that Debian is not supported yet. The example is > src:cross-toolchain-base-mipsen. > I support the cross toolchain for 12 MIPS ports: EL/BE X 32/64/N32 X R2/R6. > > > 2. It is not OK to search base headers when we configure gcc itself. > > https://patchwork.sourceware.org/project/gcc/patch/20240614121218.63375-1-...@gcc.gnu.org/ > > GCC/configure.ac detects features by the headers of linux/glibc. > Let’s have a example: we are building a mips64el cross toolchain on a > amd64 machine: > If gcc/configure.ac sees /usr/include/limits.h before than > /usr/mips64el-linux-gnuabi64/include/limits.h > Our mips64el-linux-gnuabi64-gcc will have some problem. > > And you can find the `fixinclude` in GCC for more information. I think this is a bad example on multiple levels. For one thing, limits.h is glibc and not linux. Then, it is not actually architecture-dependent[1] (otherwise it could not be in /usr/include directly) and finally, the way gcc deals with limits.h is known broken for seven years and has a patch, see see https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677. As Bastian pointed out earlier, the exact location of the kernel headers is not that important so long as gcc constructs a symlink farm for a build-time sysroot. To me, it is not obvious that keeping a non-trivial number of linux-libc-dev-$arch-cross packages duplicating content from linux-libc-dev is the superior solution to constructing changing the build of gcc-cross. > @Mattias In fact. The current gcc-X-cross searches /usr/include when > configure, it is dangerous. > --includedir=/usr/mipsel-linux-gnu/include --with-sysroot=/ > —prefix=/usr > Is not good. > The prefer way should be `—prefix=/usr` only with my patch. Again, I disagree. One of the biggest benefits of multiarch is that you get to no longer distinguish between build-time paths from run-time paths and always assume your sysroot to be / resulting in a lot of simplification. We certainly want all of our cross compilers to search /usr/include, so consulting that directory at build time actually makes sense from a multiarch point of view. The multiarch way to deal with architecture-specific differences (and headers that do not exist for all architectures) is to move them to /usr/include/<triplet> such that /usr/include only ever contains fully architecture-independent headers. So this is dangerous in the sense that we still have some architecture-dependent headers in /usr/include directly. If you happen to know any affected headers, I suggest filing bugs with the owning packages and ask them to move them to the triplet subdirectory. Helmut [1] Technically, this is a lie if we consider competing libc implementations. As Debian treats the libc as part of the architecture, we'd really require gcc's and musl's limits.h to equal here, but in reality musl just install theirs to the multiarch. However, since musl-linux-any is not bootstrappable, for practical matters, limits.h is architecture-independent on reasonable Debian architectures including ports.
