Bug#1065416: [Cross-toolchain-base-devs] Bug#1065416: linux-libc-dev claims to provide linux-libc-dev-ARCH-cross, but it doesn't do that completely
Hi Bastian,
On Mon, Mar 04, 2024 at 11:04:22PM +0100, Bastian Blank wrote:
> > Arguably, a cross toolchain build should probably search
> > /usr/include/<multiarch>. I went back and forth a bit with Matthias
> > about whether we could add this and did not fully understand his
> > reasons, but there is one technical reason we want to avoid it for now.
> > We can have both libc6-dev:TARGET and libc6-dev-TARGET-cross installed
> > and these packages can have differing versions. When that happens and we
> > search both /usr/<triplet>/include and /usr/include/<multiarch>, we'd
> > mix two glibc versions with usually bad results (been there).
>
> But this is a search path. If a file exists in one, the second one is
> not found. So nothing can happen even from version skew.
The problem arises in the reverse sense. If a file does not exist in
one, it is searched in the second and erroneously may be found. That may
make tests pass that should not pass and typically causes a link failure
later. While I do not have a concrete example at hand, I have seen this
pattern repeatedly and generally favour moving stuff out of /usr/include
to avoid this kind of confusion that causes difficult to debug problems.
This also motivates #798955 (in addition to the problem with file
conflicts).
> > The other aspect here is that it is not sufficient to add
> > /usr/include/<multiarch> to the search path as you also need
> > /usr/include to get a complete linux kernel headers experience. We
> > definitely do not want to add /usr/include, because that is known to
> > misguide configure tests performed for the target architecture.
>
> We are talking about the toolchain itself. What configure tests could
> that be? Or is that premature optimization of the gcc build?
The one case I really do remember quite well is sanitizers. These should
not be enabled in the earlier toolchain stages and failing to disable
them tends to cause linker failures. I don't think it matches the
concrete situation exactly though. You also make a good case in your
followup reporting that gcc-13-cross actually builds.
> You just said that the search path used during the build of the
> toolchain and the one for everything else are unrelated. So you are
> free to create $BUILD/tmp-include with symlinks for asm, asm-generic,
> linux.
>
> The toolchain as installed already finds all headers. So I still don't
> see why we need this in the final system.
I find this argument fairly convincing and hope Matthias also does.
Thank you
Helmut
Reply to: