Hi Matthias,

I've been fighting LIMITS_H_TEST for a long time. The basic problem with
it is that it uses different search paths from the actual compiler and
thus ends up occasionally detecting absence of limits.h when limits.h
really does exist. There have been various attempts to rectify this and
most of them are documented in the forwarded gcc ticket. Ultimately
though, I think the best course of action is deferring the check from a
build-time check to a run-time check thus using the actual compiler's
search path removing any possibility for misdetection. This can be done
using has_include_next in principle, but until recently,
has_include_next was broken on gcc in ways that would make this solution
inapplicable. These problems with has_include_next have recently been
resolved in gcc-14 and the Debian package includes a working version. As
a result I suggest that we also move forward with my proposed
LIMITS_H_TEST replacement in Debian. Upstream gcc fails to move forward
here and the problem affects Debian in particular due to our use of
multiarch and our changing of the compiler search path. Would you agree
to carry this as a Debian patch until gcc manages to fix it one way or
another? I've been using this last iteration of the patch for quite a
while now and didn't have any misdetections since.

Helmut

Control: tags -1 - patch

Sorry, but AFAICS, you didn't submit the patch upstream for review.  You
opened a bug report, but didn't send it out for review on the
gcc-patches ML.  You also didn't CC me or other Debian GCC Maintainers
in the upstrem bug report, and only opened a Debian bug report after
seven years having the upstream bug report.  I'm glad to help if you
have questions how to submit upstream patches.

yes, you used it in the context of Debian cross builds in a multiarch
environment.  No other context.

Filing a bug report seven years ago, having a proposed unreviewed patch,
and then claiming that upstream is not moving forward is a bit odd.

Please could you properly address the issue upstream to get it applied
there first? I'm happy to backport it to GCC 14 once it's accepted upstream.

Matthias

Control: forwarded -1 https://gcc.gnu.org/pipermail/gcc-patches/2024-April/650271.html
Control: tags -1 + patch

You may now find the patch. The upstream response basically was that we
should upstream the multiarch patches before this one even though
they're factually unrelated.

Yes, please. I have addressed all upstream concerns, but I'm not sure
how to make progress there.

Helmut