Added Bastian to Cc for a question below. On Sun, Aug 25, 2024 at 01:14:27AM +0800, YunQiang Su wrote: > Helmut Grohne <hel...@subdivi.de> 于2024年8月24日周六 19:20写道： > > 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.
It is the status quo that you try to defend where LIMITS_H_TEST is broken. Even now, gcc looks into /usr/include for target headers and it should not. Hence, I do not think this is not a reasonable argument for keeping the status quo. > One reason I'd prefer to keep the duplicating contents is that we may need to > have cross-toolchains for non debian official ports. With Bastian's Multi-Arch: foreign model, that is not a problem. He can just add the symlink farms for additional ports with little effort to the main linux-libc-dev package. src:linux tends to be uploaded more frequently than src:cross-toolchain-base. The way I understood Bastian is that he is ok with adding support for niche ports to the main package on demand. Last time I asked him to add an architecture, it was added relatively quickly. Bastian, would you confirm? > Keeping duplicating headers of glibc/linux-kernel won't break multiarch > support. While that is technically true, we also get all the downsides of the duplication. I still have difficulties to see the advantages of doing this. The arguments you brought forward thus far looked refutable to me. > 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. I attempted to answer this in my previous reply, but apparently the intended message did not arrive or there is a flaw in what I wrote. The idea for making building of gcc work is not that it should search /usr/include/<triplet> for the reasons that you mention. The idea was to create a symlink farm pointing to /usr/include/<triplet> inside the build directory and then pass that to gcc. In fact, the gcc build already does this more selectively. The directory is called $(builddir)/sys-include, see https://sources.debian.org/src/gcc-14/14.2.0-3/debian/rules2/#L1325 This method could be extended to also link linux kernel headers. > 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. As far as I understand it, the aforementioned part in rules2 handles exactly this case (and that's what the comment states). Would you be able to add more details as to what goes wrong here? > Thus it may be the best solution for cross-toolchains to have itself > kernel/glibc headers. I am not sure what you mean here. I find it plausible to interpret this statement both as requesting the duplicate linux headers to be kept and as agreeing with Bastian's suggestion to construct the kernel/glibc headers as a symlink farm at the time of building gcc. Helmut
