Re: gcc13 compilation error on Void Linux

[Greg Troxel <gdt%lexort.com@localhost>]

Aleksey Cheusov <vle%gmx.net@localhost> writes:

>  >> Any quick leads on this?
>
>  >>     ../../../gcc-13.2.0/libiberty/fibheap.c: In function 'fibheap_replace_key_data':
>  >>     ../../../gcc-13.2.0/libiberty/fibheap.c:38:25: error: 'LONG_MIN' undeclared (first use in this function)
>  >>        38 | #define FIBHEAPKEY_MIN  LONG_MIN
>  >>           |                         ^~~~~~~~
>
>> This is a known problem
>> https://us-central.manta.mnx.io/pkgsrc/public/reports/Linux/el9/trunk/x86_64/20240613.2355/gcc13-13.3.0/build.log
>
> The following patch solves the problem. Objections?
>
> Index: Makefile.common
> ===================================================================
> RCS file: /cvsroot/pkgsrc/lang/gcc13/Makefile.common,v
> retrieving revision 1.6
> diff -u -r1.6 Makefile.common
> --- Makefile.common	24 Apr 2024 10:56:06 -0000	1.6
> +++ Makefile.common	20 Jun 2024 16:34:06 -0000
> @@ -94,6 +94,10 @@
>  MAKE_ENV.NetBSD+=	ac_cv_func_uselocale=no
>  MAKE_ENV.SunOS+=	ac_cv_func_mkostemp=no
>
> +# The following line fixes build failure on Linuxes with gcc with
> +# -DFORTIFY_SOURCE enabled by default.
> +CPPFLAGS.Linux+=	-O2
> +
>  .if !empty(PKGSRC_COMPILER:Mclang) || ${OPSYS} == "DragonFly"
>  CONFIGURE_ARGS+=	--disable-bootstrap
>  .endif

Well, not really, but an error that a symbol is not declared going away
iwth -O2 (vs -O3?) does not make sense.  It seems unlikely to be a
correct fix, and instead a band-aid to avoid the real issue.

LONG_MIN is in limits.h, so this smells like a failure to include the
right headers.

It would be good to hear from people that understand this better, and
your theory of what is going on.