[vlc-devel] [PATCH 1/1] build: define _FORTIFY_SOURCE only if it is not already defined

[Rémi Denis-Courmont]

Le keskiviikkona 31. elokuuta 2016, 22.05.58 EEST Janne Grunau a écrit :
> On 2016-08-27 23:11:02 +0200, remi at remlab.net wrote:
> >    Hello,
> >    
> >    Le 27 aout 2016 17:01, Janne Grunau <janne-vlc at jannau.net> a ecrit :
> >    > On 2016-08-13 18:48:47 +0200, Janne Grunau wrote:
> >    > > Fixes "_FORTIFY_SOURCE redefined" warnings in every file which
> >    
> >    includes
> >    
> >    > > config.h if _FORTIFY_SOURCE is predefined by the toolchain.
> >    
> >    Broken toolchain, fix toolchain. Nack.
> >    
> >    The _whole_ point of _FORTIFY_SOURCE is to be able to set it in the
> >    program or packaging rule. The toolchain has no business setting it, as
> >    any other "feature" macro.
> 
> I don't see a significant difference between pre-defining
> _FORTIFY_SOURCE via gcc specs or CFLAGS/CXXFLAGS in packaging rules.

What´s the point in the libc header files making _FORTIFY_SOURCE configurable 
if the toolchain forces it? _FORTIFY_SOURCE  might just as well be removed and 
the header files hard-coded accordingly. IMHO, it is nonsensical, for 
_FORTIFY_SOURCE or for any other _x_SOURCE macro. Specifically, the default 
values should be set in features.h or similar, not in the machine 
specification.

> Both cause a massive amount of unnessary "_FORTIFY_SOURCE redefined"
> warnings. There are package build systems which define _FORTIFY_SOURCE
> for all packages. I'll happily resubmit the patch with an updated
> description mentioning only packaging rules.

I can easily imagine why distributions may want to set _FORTIFY_SOURCE by 
default in their respective packaging system. But then the issue should 
presumably be dealt with in the corresponding specific VLC packaging rules, 
not the upstream VLC build system.

And leaving design principles aside, downgrading/lowering _FORTIFY_SOURCE 
seems wrong. The patch seems to do exactly that.

-- 
Rémi Denis-Courmont
http://www.remlab.net/