On Tue, 5 Mar 2024 09:50:27 +0100 Helmut Grohne <[email protected]> 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
