Re: gcc13 compilation error on Void Linux

[Aleksey Cheusov <vle%gmx.net@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.

Please have a look at email I replied to. There you'll find a required
information and detailed analysis.

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