Mail Archives: djgpp/2000/07/18/11:39:53
From: Andris Panavis, <pavenis AT lanet DOT lv>
Date: Thu, 13 Jul 2000 19:35:08 +0200
> On 7 Jul 2000, at 20:12, Juan Manuel Guerrero wrote:
>
> > This is a port of GNU Gettext 0.10.35 to MSDOS/DJGPP.
>
[snip]
> > removed. The gettext() stub in intl-comp.c has been defined out and
> > a macro, that will expand to gettext__, has been introduced in intlh_inst.in
> > (libintl.h when installed in $DJDIR/include).
> > The gettext function is now available as gettext or gettext__.
>
> It's not fixed completely.
Yes, this is true and it will propably **never** be fixed completely.
As the readme file and the announce tells, the gettext function has
been replaced by a macro that expands into gettext__. I have assumed
that every user would understand that he had to undefine the gettext
macro from libintl.h **before** including the conio.h header.
This was my error. The readme file had to be much more explicit. Sorry.
There are two cases:
1) The user wants to use both gettext functions in the same file.
In this case an "alias" must be used for the GNU gettext function.
In this case the code should look like:
#include <libintl.h>
#undef gettext
#define _ gettext__ // this is for NLS support.
#define gettext gettext // this is for gettext from conio.h.
#include <conio.h>
Now you are ready to use both gettext functions in the same file.
gettext() from conio.h as gettext and gettext() from GNU gettext
as '_' or as gettext__(). The use of '_' as alias for gettext__()
is typical for all GNU packages.
Of course the above example works only if conio.h is included
*after* libintl.h. I do not like this header sequence dependency.
But this is the way the port works.
2) The user wants to use the GNU gettext function and needs to include
the conio.h header but without using the gettext function.
In this case the code should look like:
#include <conio.h>
#undef gettext
#include <libintl.h>
Once again the order of the headers matter.
It is important to realize that gettext is a macro.
Of course, the origin of this difficulty is the fact that one
tries to include to headers that defines two different functions
using the same name. This will probably never work.
With my first port I have tried to avoid all this difficulties.
The trick was the function renaming I had proposed. This means
I had replaced gettext() by GetText(). This was exactly the same trick
used by all the previuos ports of GNU gettext. I was *very* sorprised
that my version of the port had been objected but the previous ones not.
Date: Sun, 16 Jul 2000 14:13:42 GMT
From: "Tim 'Zastai' Van Holder" <zastai AT hotmail DOT com>
> <pavenis AT lanet DOT lv> wrote in message news:396E19EC DOT 28107 DOT 5D732F AT localhost...
> > It's not fixed completely.
> >
> > I'm getting errors from following example:
> > -------------------------------------------------
> > #include <libintl.h>
> > #include <conio.h>
> > -------------------------------------------------
> > In file included from intl.c:2:
> > d:/djgpp/include/conio.h:74: conflicting types for `gettext__'
> > d:/djgpp/include/libintl.h:52: previous declaration of `gettext__'
> > -------------------------------------------------
> >
> > If I swap #include statements then example compiles Ok.
> >
> > Andris
>
> Looks like he's made the unfortunate mistake of doing '#define gettext
> gettext__', which un-fixes the nameclash
> he fixed by renaming libintl's gettext to gettext__. My previous port didn't
> do this; instead it defined the
> commonly used _(foo) macro to use gettext__. While not defining gettext
This is not completely true.
For your information:
1) gettext() is a stub that calls gettext__(). gettext__() is the real working function
of GNU gettext.The code of gettext is in file intl-compat.c and the code of gettext__()
is in gettext.c. So gettext() has *never* been renamed into gettext__() to avoid the name clash.
As explained in the readme file the gettext() stub, that directely calls gettext__(),
has been defined out. Because the stub has been defined out, libintl.a and libc.a can
be used together without causeing linker errors (ld will not report double symbols anymore).
2) I have defined gettext to gettext__. This is *not* an unfortunate mistake,
this is *full* intentional. Now gettext__() is also available as gettext(). gettext is a macro
that expands into gettext__(). It is important to notice that gettext() **must** be available
or configuration of all existing DJGPP ports of GNU packages **will** fail. This was one of
the consequences of a discussion at djgpp-workers.
One of the goals of this port is that every existing DJGPP port could be reconfigured
for NLS support **without** having to modify configure.in, gettext.m4 and the sources.
This is simple **impossible** if gettext() is renamed like proposed above by Tim 'Zastai' Van Holder.
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
Date: Sun, 16 Jul 2000 19:11:34 +0300 (IDT)
> On Sun, 16 Jul 2000, Tim 'Zastai' Van Holder wrote:
>
> > My previous port didn't do this; instead it defined the
> > commonly used _(foo) macro to use gettext__.
>
> Doesn't this break configure scripts which probe the system for gettext
> being installed?
Of course. This choose will break the hole configuration process. In this port,
gettext has been *intentionaly* choosen as a macro that expands into gettext__.
gettext__() will not been found in DJGPP's libc.a so that the configure script
will check for gettext() in libintl.a
No changes to configure.in nor gettext.m4 are needed at all. This implies that neither
the DJGPP maintainer nor the user must install perl, automake and autoconfig
to reconfigure his package for NLS support.
From: "Tim 'Zastai' Van Holder" <zastai AT hotmail DOT com>
Date: Sun, 16 Jul 2000 18:16:17 GMT
> Eli Zaretskii <eliz AT is DOT elta DOT co DOT il> wrote in message
> >
> > On Sun, 16 Jul 2000, Tim 'Zastai' Van Holder wrote:
> >
> > > My previous port didn't do this; instead it defined the
> > > commonly used _(foo) macro to use gettext__.
> >
> > Doesn't this break configure scripts which probe the system for gettext
> > being installed?
> No (well, not usually). GNU programs generally use the AM_GNU_GETTEXT
> macro to add i18n support (Cygnus trees use CY_GNU_GETTEXT). As of serial
> 104 (or thereabouts) of gettext.m4 (the macro file that defines
> AM_GNU_GETTEXT),
> Ulrich Drepper, the gettext maintainer, added a workaround so gettext won't
> be found
> in libc under DJGPP; it is then found later in libintl.
[snip]
I have never mailed to Ulrich Drepper so I have no idea about his future plans
but for the first version of the port I uploaded, I have inspected the following files:
gettext.m4 (serial #5) from gettext-0.10.35
gettext.m4 (serial #105) from grep-2.5a
gettext.m4 (serial #107) from tar-1.13.17
gettext.m4 (serial #109) from sh-utils-2.0i
I have also inspected the ones from binutils-2.95 and gdb-4.18 (CYGNUS versions).
I tell this because the first version of the port I had uploaded worked in
exactely the same way as described by Tim 'Zastai' Van Holder. The user had to
run aclocal to create a new aclocal.m4 that contained the NLS macros from the
gettext.m4 file. The gettext.m4 file was installed by the gtxt035b binary package in
$DJDIR/share/aclocal. After inspecting the above files I decided to replace serial #5 by serial #107.
I have never found **any ** kind of DJGPP support code in **anyone** of the above mentioned files.
I have tested #5, #105 and #107 and everyone has found gettext in libc.a. Of course
the wrong gettext. I have added DJGPP support to gettext.m4 (serial #107) and
explained the way it worked at djgpp-workers. The port has been rejected due to
the use of aclocal.
The conclusion of all this is that I have two versions of this port available:
1) A version where gettext() is renamed.
This renaming implies the well known configuration difficulties.
2) A version where gettext () is not renamed.
In this version the conflict between gettext from conio.h
and libintl.h is not cleanly removed. gettext() is available
so the packages can be configured without running automake,
aclocal, autoconf and without modifying the sources.
IMHO, before trying to fix anything in one of the ports, a crucial question
should be answered:
1) Do we want to get NLS support out-of-the-box for every existing and future
DJGPP port ?
or
2) Do we want to maintain compatibility with an old BORLAND compiler that is
no longer produced nor maintained by BORLAND/IMPRISE ?
If the first is wanted then conio.h has to be changed, IMHO.
If the second is wanted then libintl.h must be changed. This means
gettext must be renamed with the well known consequences for the
configuration process.
I have no preferences and I am not lobbying for one or the other of the
two answers but IMHO we need a radical solution.
Any suggestion that helps to solve this problem once and for all
would be seriously appreciated.
Regards,
Guerrero, Juan Manuel
- Raw text -