Re: Fixing configure failures from newer gcc

[Paolo Vincenzo Olivo <vins%NetBSD.org@localhost>]

On 25/10/19 09:29AM, Greg Troxel wrote:
> 
> pkgsrc has had a mechanism to deal with this for several years, thanks
> to nia@ who implemented it after much discussion.
> 
> See FORCE_C_STD in mk/compiler.mk. 

I'm aware of the FORCE_C_STD and USE_CC_FEATURES (+ CXX variants)
framework, which I find definitely cleaner and more consistent than
appending C/C++ standards requirements to USE_LANGUAGES, as we used to
do before the switch, IIRC. 

> If a program is written to C99 and -
> doesn't add -std, our *existing practices* say we should:
> 
>   - Set FORCE_C_STD=c99 (or gnu99)
>   - If the program is in C99 but the README doesn't say that, file a bug
>     upstream about that.
>   - Find or file a bug upstream that it doesn't set -std
>   - Add a comment that upstream doesn't set std, with the bug report URL
> 
>   - Probably, file a bug upstream that it doesn't build as C23 under gcc14.

Thanks for the pointer, this is very useful, and could be added to the
pkgsrc developer's guide, if it hasn't been already.
I have been adding FORCE_C_STD to packages claiming to be written in
C99 but not passing -std=c99 in CFLAGS.

For what it's worth the most common cause of breakage I've come across,
is software insisting to pass -std=c99 (or even c89), but using
alloca(3), getopt(3), strdup(3) and so on.

The most transparent solution in this case is to add:  

    BUILDLINK_TRANSFORM+=		opt:-std=c99:-std=gnu99

to the package Makefile. 

> 
> My take is that if you the maintainer have analyzed and understood, it's
> fine.  But there should be a comment in the pkgsrc makefile where the
> -Wno is added that explains the situation well.

Got it, thx.