From: "Juan Manuel Guerrero" Organization: Darmstadt University of Technology To: djgpp AT delorie DOT com Date: Tue, 18 Jul 2000 08:12:30 +0200 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Subject: Re: ANNOUNCE: DJGPP port of GNU gettext-0.10.35 CC: eliz AT is DOT elta DOT co DOT il, pavenis AT lanet DOT lv, zastai AT hotmail DOT com X-mailer: Pegasus Mail for Windows (v2.54DE) Message-ID: <9CE31E42431@HRZ1.hrz.tu-darmstadt.de> Reply-To: djgpp AT delorie DOT com From: Andris Panavis, 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 #undef gettext #define _ gettext__ // this is for NLS support. #define gettext gettext // this is for gettext from conio.h. #include 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 #undef gettext #include 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" > wrote in message news:396E19EC DOT 28107 DOT 5D732F AT localhost... > > It's not fixed completely. > > > > I'm getting errors from following example: > > ------------------------------------------------- > > #include > > #include > > ------------------------------------------------- > > 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 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" Date: Sun, 16 Jul 2000 18:16:17 GMT > Eli Zaretskii 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