-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 29/08/16 23:32, Steffan Karger wrote:
> HI,
> 
> On 29 August 2016 at 23:03, David Sommerseth 
> <[email protected]> wrote:
>> On 29/08/16 22:45, David Sommerseth wrote:
>>> On 28/08/16 21:42, Steffan Karger wrote:
>>>> Previously, we would use the compiler's default C version,
>>>> which defaults to gnu89 for GCC < 5, gnu11 for GCC > 5, and
>>>> c11 for clang, but might even differ per distro.
>>> 
>>>> One of the reasons to accept the gnu89 default of GCC < 4.9,
>>>> was that MSVC didn't support c99.  But in MSVC 2015, MS
>>>> finanally fixed that.
>>> 
>>>> Having to support c89 in the codebase occasionally forces us
>>>> to write less readable code, for example by forcing all
>>>> declaration to be at the starting of a block (which includes
>>>> 'for loop initial declarations').
>>> 
>>>> Let's be clear about what standard we obey, and stop
>>>> punishing ourselves with c89/gnu89.  Let's switch the master
>>>> branch to c99.
>>> 
>>>> Signed-off-by: Steffan Karger <[email protected]> --- 
>>>> configure.ac | 1 + 1 file changed, 1 insertion(+)
>>> 
>>>> diff --git a/configure.ac b/configure.ac index
>>>> 9189c94..16cab19 100644 --- a/configure.ac +++ b/configure.ac
>>>> @@ -1125,6 +1125,7 @@ if test "${enable_pkcs11}" = "yes";
>>>> then ) fi
>>> 
>>>> +CFLAGS="${CFLAGS} -std=c99" if test "${enable_pedantic}" = 
>>>> "yes"; then enable_strict="yes" CFLAGS="${CFLAGS} -pedantic"
>>> 
>>> 
>>> I so much wants to give this an ACK.  But this breaks CentOS 5 
>>> builds very badly.  The glibc-headers isn't prepared for C99
>>> on that distro.
>>> 
>>> I took the latest git master where I could do a successful
>>> build. Then I applied just this patch, and here is the
>>> explosion: <http://paste.fedoraproject.org/417049/14725031/>
>>> 
>>> To move towards C99, we need to add some tricks which makes
>>> this not requiring users to overwrite C99 with C89.  That
>>> should happen automatically.
>>> 
>>> Some CentOS 5.11 details: glibc-2.5-123.el5_11.3 
>>> glibc-headers-2.5-123.el5_11.3 gcc-4.1.2-55.el5 
>>> openssl-0.9.8e-40.el5_11 lzo-2.02-2.el5.1
>> 
>> Did a bit more testing.
>> 
>> -std=gnu89, -std=gnu99 Works very fine (compiles without
>> errors).
>> 
>> -std=c99 Makes glibc-headers explode, as already described
>> 
>> -std=c89 Makes the LZ4 library we're shipping explode.
> 
> Hm, that's too bad.  But I think we should still go for c99,
> rather than gnu99.  That should actually result in *more* portable
> code on our side.  The CentOS package maintainer can then easily
> patch configure.ac (or configure) to use gnu99 for arcane
> platforms.

For the stock CentOS 5 package, it probably won't matter.  That's
indirectly maintained by Red Hat doing all kind of backports whenever
needed.

For the Fedora EPEL releases (which keeps our release cycles fairly
tight), I'm adding Jon to this discussion directly as the main Fedora
package maintainer for OpenVPN.

Any thoughts on this, Jon?


- -- 
kind regards,

David Sommerseth

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAEBAgAGBQJXxLU9AAoJEIbPlEyWcf3y+AQP/iuVPJOsfilHtPPa9UP/MHe3
gPf+LrWBQ5YhkvW06MC9dfWRaDSf2PILj6dKG5kj83hdfhv/CcyJZCLYZLlhiaqS
ONxcndskI3geIbAxsx/QCSQ1GghTsc/jwFKcYlrDBq8RA34s0KQBmquKtUyoMX7E
/YldciIuK5hCEr/6+Kx5ekyszceGV6i6RG4+Mevkf6CEHvOgS8NUFhcw2zY++Ook
E1FkSLcrw/yc8HnChIR8z4qvFpvKmQyTQ9mN7/noqSC4rc/ESrWx0sAj48g7be+l
PMfQ94O8au4QYysb9AWFPhX2b23hNJPavMGYbZW07d2ZFs6kRs7I5bPSSkp/Vnxf
3rq27Hmo6pKFxIR/52w9ysNU4vrUVshim9Al2UytgI6+T3ClxWJSGfjaYMd5tCL4
sPyNnQHhjXo2WIxeCIbTTkIUEtVVQit67ZvyU6+aL+S5gB56Nvw+/UORyQfr7hx/
5q7RUvNo65XLVXHXNhoXKSHsSEwiSCQ5oQI71Lvh8omKLcDlKF6LTBIt7p8CBTk1
vD4foQSF8ZW/0FEFIpY9eXEpbLcIZk8wiFHaXS9X6etocw0JXuG+0PHlHxz++0wg
SIX/ql3xAwdEmYo3gK0LzPVy7gjgd4mwSSvudKCQSz1XPVJt0XTn0OitxCA/9IJt
mL5G75qaB4WjsLT4Ot7T
=LInq
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
_______________________________________________
Openvpn-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openvpn-devel

Reply via email to