• Bug#1069066: LIMITS_H_TEST is frequently wrong on Debian

    From Helmut Grohne@21:1/5 to All on Mon Apr 15 21:10:01 2024
    Source: gcc-14
    Tags: patch upstream
    Forwarded: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80677
    User: helmutg@debian.org
    Usertags: rebootstrap
    X-Debbugs-Cc: debian-cross@lists.debian.org

    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

    --- a/src/gcc/limitx.h
    +++ b/src/gcc/limitx.h
    @@ -29,7 +29,7 @@
    #ifndef _GCC_LIMITS_H_ /* Terminated in limity.h. */
    #define _GCC_LIMITS_H_

    -#ifndef _LIBC_LIMITS_H_
    +#if !defined(_LIBC_LIMITS_H_) && __has_include_next(<limits.h>)
    /* Use "..." so that we find syslimits.h only in this same directory. */
    #include "syslimits.h"
    #endif
    --- a/src/gcc/limity.h
    +++ b/src/gcc/limity.h
    @@ -3,7 +3,7 @@

    #else /* not _GCC_LIMITS_H_ */

    -#ifdef _GCC_NEXT_LIMITS_H
    +#if defined(_GCC_NEXT_LIMITS_H) && __has_include_next(<limits.h>)
    #include_next <limits.h> /* recurse down to the real one */
    #endif

    --- a/src/gcc/Makefile.in
    +++ b/src/gcc/Makefile.in
    @@ -3139,11 +3139,7 @@
    sysroot_headers_suffix=`echo $${ml} | sed -e 's/;.*$$//'`; \
    multi_dir=`echo $${ml} | sed -e 's/^[^;]*;//'`; \
    include_dir=include$${multi_dir}; \
    - if $(LIMITS_H_TEST) ; then \
    - cat $(srcdir)/limitx.h $(T_GLIMITS_H) $(srcdir)/limity.h > tmp-xlimits.h; \
    - else \
    - cat $(T_GLIMITS_H) > tmp-
  • From Matthias Klose@21:1/5 to All on Wed Apr 24 13:30:01 2024
    Control: tags -1 - patch

    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?

    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.

    I've been using this last iteration of the patch for quite a
    while now and didn't have any misdetections since.

    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)