bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Solaris, GCC and libintl


From: Eric Botcazou
Subject: Re: Solaris, GCC and libintl
Date: Wed, 13 Sep 2006 15:52:23 +0200
User-agent: KMail/1.7.1

> You mean http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23541, I assume.

Sorry, the correct shortcut is http://gcc.gnu.org/PR23541.

> You have a funny logic. You note that the problem is not reproducible
> in gettext itself, and conjecture that it is due to gcc's own build
> infrastructure of the intl/ directory - which I'm tempted to conjecture
> too, after a look at [1] - and then you propose to change the original
> gettext!

Note that I didn't mention "bug", "problem" or "fix" for gettext.  And my 
suggestion was purely based on considerations of consistency for the order
of inclusion of header files.  I'd for example note that ngettext.c has

#include "gettextP.h"
#ifdef _LIBC
# include <libintl.h>
#else
# include "libgnuintl.h"
#endif

#include <locale.h>

whereas dgettext.c has

#include "gettextP.h"

#include <locale.h>

#ifdef _LIBC
# include <libintl.h>
#else
# include "libgnuintl.h"
#endif

in the current sources so I'd again suggest to change one of them, probably 
the latter into the former.

However I was indeed convinced that this discrepancy in the current sources 
was equivalent to the one in the GCC directory and, therefore, that the build
infrastructure was the trigger of the GCC bug.

> The answer is that gcc's copy is based on gettext-0.12.1 whereas gettext
> has this in the ChangeLog:
>
> 2003-09-04  Bruno Haible  <address@hidden>
>
>         * dgettext.c: Include <locale.h> after gettextP.h, not before. This
>         ensures that libintl_dcgettext is correctly declared on Solaris.
>         (Needed because Solaris <locale.h> includes libintl.h.)
>         * dngettext.c: Likewise, for the libintl_dcngettext declaration.

Oops, I totally missed this ChangeLog entry. :-)

> All you have to do is to ensure that this patch is applied to the
> relevant branches of the gcc repository.

Yes, I'm going to do so.

Thanks for your help!

-- 
Eric Botcazou




reply via email to

[Prev in Thread] Current Thread [Next in Thread]