On Tue, 5 Mar 2024 09:50:27 +0100 Helmut Grohne <
helmut@subdivi.de> wrote:
> 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
>
>
>
+880 1406-311377number contact details