Re: Trouble compiling CVS with g++=3.2.2

From Gordon Paynter
DateMon, 20 Jan 2003 17:50:01 +1300 (NZDT)
Subject Re: Trouble compiling CVS with g++=3.2.2
In-Reply-To (3E2B5C6C-8DE75108-cs-waikato-ac-nz)
Thanks for your reply John,

> We've sometimes had problems like this, and I think it was due to things
> getting #defined in some of our header files.

It looks like this is the case.

> /home/paynter/gsdl/src/mgpp/text$ g++ -E -DHAVE_CONFIG_H -I../../..
> -I../lib -I. -g -O2 -DSILENT -DSHORT_SUFFIX mgpp_passes.cpp
>
> to see what the pre-processor is doing (this shows all the parsing of
> the header files etc - search for "bindtextdomain" which is the
> prototype in libintl.h that is bailing out).

Actually, in my version of libintl.h (which will, presumably, be coming to
a GNU compiler near you soon) line 81 of libintl.h contains:

extern char *textdomain (__const char *__domainname) __THROW;

and bindtextdomain appears a few lines later. It looks like this clashes
with the #define you described below:

> gsdl/src/mgpp/lib/sysfuncs.h looks very suspicious, especially around
> line 341 :)
>
> 337 #if ENABLE_NLS
> 338 #include <libintl.h>
> 339 #define _(Text) gettext (Text)
> 340 #else
> 341 #define textdomain(Domain)
> 342 #define _(Text) Text
> 342 #endif

When I compile mgpp_passes the preprocessor must pick up the #define on
line 341, and then later on loads libintl.h also and substituues
textdomain into the extern char * declaraion above. Then libintl.h will
be sent to g++ with "extern char * throw..." on line 81--which is
consistent with the error message: "usr/include/libintl.h:81: parse error
before `throw'".


The obvious solution is to use a name other than textdomain for our
#define. Does anyone have any prior knowledge of what it is or does?
Also, are the files in mgpp/lib/*.h referenced outside the mgpp tree?

If nobody else wants it, I'll fix it myself, later this week. I don't
have a working gsdl on my laptop either at the moment due to Expat/perl
library compatabilities in Debian unstable for ppc.


Thanks again,
Gordon