cURL / Mailing Lists / curl-library / Single Mail


Third party header brokenness toleration [Was: Our GnuTLS support needs polish]

From: Yang Tse <>
Date: Mon, 8 Aug 2011 16:46:23 +0200

2011/8/8 Daniel Stenberg wrote:

> * A third bug that seems to be unrelated to GnuTLS is that we don't properly
>  replace -I with -isystem when we use --enable-debug or -enable-werror so we
>  get warnings on the GnuTLS 3.0.0 headers because they use trailing commas
>  in enums and gcc warns about that with pedantic warning options.

If we have to call this a bug, I would not say it is a bug in our side
but a bug in third party header file. This is my reasoning...

The build system (configure script) heavily depends among other things
on header file correctness. And tries its best to ensure that if a
build succeeds it will be a proper build. In order to achieve this,
among other things, compilation of header files are done in a myriad
of places and in order to use something it must survive proper

As a matter of fact our checks are not yet strict enough. As a result
of this, a bug in a GNU header file when used with intel compiler icc
9.1 is what has rendered icc 9.1 autobuilds in the generation of
binaries that would segfault for no apparent reason for more than two
years. Fortunately this has been fixed now in our code, but it has
been a very frustrating situation and chasing it down very time

Our configure script currently replaces -I with -isystem when using
GCC for those paths provided in CFLAGS and CPPFLAGS before the
configure script runs. This is done this way to try to ensure that all
compilation tests that use the bad headers can run when using
--enable-warnings and -Werror.

If we modify any -I to -isystem in the middle of the configure run,
formally, previous checks should be invalidated given that the
resulting configuration file might have false positive and false
negative results in it.

Additionally, include paths that are obtained with pkg-config should
equally be modified from -I to -isystem, and separate variables might
be required in order to emmit our own dependencies.

We could modify all -I to -isystem near the end of the configure
script but obviously configure checks would have run using plain old
-I and not -isystem.

I really wonder why anyone would want us to subvert the intention and
functionality of --enable-warnings and/or -Werror. They get what they
asked for, the strictest error checking available for the resulting
build, and that includes third party headers involved in the build

If they don't want the errors from third party libraries and yet want
a debug build, they can use --enable-debug along with
--disable-warnings, and obviously not use -Werror, otherwise they will
get what they have asked for. Or as an alternative, from the very
beginning provide an include path to the buggy header files in CFLAGS
or CPPFLAGS, before configure runs.

As a note relative to this, I don't remember now which platform is
doing it but among other things they patch from our distribution is
actually removing the -isystem stuff we introduce in the configure

List admin:
Received on 2011-08-08