Re: [bug-gperf] gperf vs gcc-4.4

[Bruno Haible]

Priit Laes wrote:
> >   - the version number of gperf being used to generate the processed file?
>       GNU gperf 3.0.4

Good, this version is new enough to exclude problems with newer GCC due to
the changed semantics of 'inline'.

> >   - the processed file?
>       http://plaes.org/files/2009-Q3/HTMLEntityNames.c
> >   - the source code of the source file that #includes the processed file?
> Hum? It seems to be compiled straight into library...

OK, so that was compiled as a C file and thus created a 'findEntity' function
with C linkage.

> >   - the output of
> >        $ nm --dynamic .libs/libwebkit-1.0.so | grep findEntity
> [output]
>                        U _Z10findEntityPKcj
> 000000000138d1a8 T findEntity
> [/output]

Here you see that 'findEntity' exists as a function with C linkage but some
other compilation unit needs it as a function with C++ linkage.

> >   - it could be that the functions are compiled as C functions and you
> >     refer to them from C++ without 'extern "C"' declarations.

> This might be the case.. (?) So one should create a cpp file and 
> #include the generated c file like this:
> 
> [output]
> extern "C" {
> #include "gperf-generated-c-code.c"
> }
> [/output]

This would not help, it would not change anything.

What you need is either to #include the generated C file like this:
  #include "gperf-generated-c-code.c"
from a C++ compilation unit. Or directly name the generated file
"gperf-generated-c-code.cc", and tell gperf to generate C++ code instead
of ANSI C code.

Or to use the following declaration in your C++ compilation units:

  extern "C" {
  extern const struct Entity *findEntity (const char *str, unsigned int len);
  }

Bruno