Bug#1065416: requesting input on recent posts to #1065416
Helmut Grohne <helmut@subdivi.de> 于2024年8月24日周六 19:20写道：
>
> 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-syq@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.
>
Sure. That's why I think that we should keep kernel headers in
/usr/<triple>/include for now before that we can be sure that these problem
has been fixed.
> 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.
>
One reason I'd prefer to keep the duplicating contents is that we may need to
have cross-toolchains for non debian official ports.
> > @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.
>
Keeping duplicating headers of glibc/linux-kernel won't break multiarch support.
> 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.
>
The configure.ac of GCC won't try to find headers in multiarch directories.
So if we move all architecture-dependent headers into /usr/include/<triple>,
gcc will have some trouble to build itself, especially for multilib support.
That's why gcc-multilib symlinks /usr/include/x86_64-linux-gnu/asm to
/usr/include/asm.
You can have a try to build gcc without gcc-multilib installed with
../configure --target=x86_64-linux-gnu --enable-multilib
Or you can have a try to build cross-gcc with gcc-multilib installed:
../configure --target=aarch64-linux-gnu
Then some mistake of feature detection will happen.
Thus it may be the best solution for cross-toolchains to have itself
kernel/glibc headers.
> 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.
>
--
YunQiang Su
Reply to: