Failed compilation of libcerf: any hints?

[Joshua Root]

On 2013-7-18 02:46 , j.wuttke wrote:
> Dear Josh:
> 
>> The -pedantic option causes warnings to be issued for any code that does
>> not conform to ISO C. The -Werror option causes all warnings to become
>> errors. Thus, using these two options together when compiling code that
>> uses any GNU extension will cause the compilation to fail.
> 
> This is not fully true; man gcc (version 4.7) says:
> 
>            Some users try to use -pedantic to check programs for strict
> ISO C
>            conformance.  They soon find that it does not do quite what they
>            want: it finds some non-ISO practices, but not all---only
> those for
>            which ISO C requires a diagnostic, and some others for which
>            diagnostics have been added.
> 
>            A feature to report any failure to conform to ISO C might be
> useful
>            in some instances, but would require considerable additional
> work
>            and would be quite different from -pedantic.  We don't have
> plans
>            to support such a feature in the near future.

Yes, all true. Nonetheless, removing -pedantic from AM_CFLAGS stops this
warning from being issued and allows compilation to succeed.

>> it's still bad to use -pedantic and -Werror with this code.
> 
> With this particular code? Why?

Because -pedantic adds a warning with this code and -Werror turns it
into an error.

However, we generally remove -Werror from compiler flags in MacPorts
anyway because new compiler versions tend to add more warnings, which
makes ports fail to build despite the code being no more incorrect than
it ever was. (For example, clang issues warnings about putting
parentheses around expressions to improve readability.)

>> Imaginary constants really are a GNU extension, i.e. not allowed in
>> the ISO C99
>> standard:
>>
>> <http://gcc.gnu.org/onlinedocs/gcc/Complex.html>
> 
> ISO C99 has macros I and _Complex_I. These constants are used in
> libcerf/lib/def.h
> to #define C(a,b).
> 
> So for the moment I tend to think that our code is clean ISO C99, and that
> there is no other problem besides the broken support for complex.h in
> gcc-4.2.

OS X 10.6 (or rather Xcode) comes with a /usr/include/complex.h that
doesn't look like it's part of GCC, and appears to be the only complex.h
on the system. It does this:

#define _Complex_I (__extension__ 1.0iF) /* constant expression of type
const float _Complex */
#define I _Complex_I

and 'I' is if course used in libcerf's defs.h. The definition of
_Complex_I is using the GCC extension syntax for imaginary constants.
You could consider this a bug in the header, I suppose.

- Josh