[vlc-devel] [PATCH 1/1] build: define _FORTIFY_SOURCE only if it is not already defined
remi at remlab.net
Wed Aug 31 22:26:24 CEST 2016
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
> 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.
More information about the vlc-devel