Hi Helmut
On Tue, Mar 05, 2024 at 09:50:27AM +0100, Helmut Grohne wrote:
> 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.
But you want /usr/include to be found. Otherwise you would not be able
to use most of the libraries for cross compiling.
> . 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).
In this case here, this would just find kernel headers for a different
version. Those are essentially a headers only library, nothing is
available for linking. And all the headers provided in /usr/include are
the same for all architectures.
So moving stuff out of /usr/include might be a good idea if the -dev
package is itself arch dependent.
> 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.
Yep. My problem is: I tested stuff, not everything of course, and did
not see any breakage. Also I checked the values I know could influence
that and they say it is fine. So at some point I have to assume it is
not broken, as exhaustive search is simply not possible.
The only statement in this bug report is now: it is located in a
different location, so it is broken. No single piece of evidence is
shown, like broken builds or some other ways to see the brokeness.
Regards,
Bastian
--
A princess should not be afraid -- not with a brave knight to protect her.
-- McCoy, "Shore Leave", stardate 3025.3
