delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2001/11/12/09:34:01

From: "Juan Manuel Guerrero" <ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De>
Organization: Darmstadt University of Technology
To: lauras AT softhome DOT net
Date: Mon, 12 Nov 2001 15:23:28 +0100
Subject: Re: Small djgpp-specific fix to gettext
CC: djgpp-workers AT delorie DOT com
In-reply-to: <20011020171738.3713.qmail@softhome.net>
X-mailer: Pegasus Mail for Windows (v2.54DE)
Message-ID: <CA6229B34AC@HRZ1.hrz.tu-darmstadt.de>
Reply-To: djgpp-workers AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: djgpp-workers AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Excuse the terrible delay but i was very busy.
Netherless I hope the answer/info is still of some use.


On Sat, 20 Oct 2001, Laurynas wrote:
> Build process of gettext-0.10.40 fails in testsuite because it redefines
> gettext macros to something else. However, libgnuintl.h unconditionally
> defines them on DJGPP, while IMHO this is required iff conio.h has been
> previously defined. The tiny patch below allows building all programs in
> the testsuite.

Sorry, but I can not reproduce this difficulty at all. I have downloaded
gtxt040s.zip from some simtel.net mirror to make sure that I am testing
the same as you have tested/used. I have compiled and run the testsuite
of the package out-of-the-box, this means that I have used the makefiles and
all other genereated files that the package supplies without changing them.
I have compiled and tested the package under two different conditions:
1) using stock djgpp tools, this means: gcc302, bnu2112, djdev203, bsh204, etc.
and
2) using the same tools as in 1) except that djdev203 has been replaced by
   actual CVS djgpp (timestamp: 2001-11-08).

Naturally, in case 1), it is exclusive responsibility of the user to replace
the stock conio.h and conio.o with the supplied ones by gtxt040b.zip or the
complete testsuite may fail. I have configured, compiled and run the testsuite
a couple of times using both djdev203 and CVS djdev. I have always got the
following output:
  Making check in tests
  make.exe[1]: Entering directory `e:/_test/gtxt-010.40/tests'
  E:/DJGPP-2.04/BIN/make.exe  check-TESTS
  make.exe[2]: Entering directory `e:/_test/gtxt-010.40/tests'
  PASS: gettext.1
  PASS: gettext.2
  PASS: msgcmp.1
  PASS: msgcmp.2
  PASS: msgfmt.1
  PASS: msgfmt.2
  PASS: msgfmt.3
  PASS: msgfmt.4
  PASS: msgmerge.1
  PASS: msgmerge.2
  PASS: msgmerge.3
  PASS: msgmerge.4
  PASS: msgmerge.5
  PASS: msgunfmt.1
  PASS: xgettext.1
  PASS: xgettext.2
  PASS: xgettext.3
  PASS: xgettext.4
  PASS: xgettext.5
  PASS: xgettext.6
  PASS: xgettext.7
  PASS: xgettext.8
  PASS: xgettext.9
  PASS: plural.1
  PASS: plural.2
  ===================
  All 25 tests passed
  ===================
  make.exe[2]: Leaving directory `e:/_test/gtxt-010.40/tests'
  make.exe[1]: Leaving directory `e:/_test/gtxt-010.40/tests'
  make.exe[1]: Entering directory `e:/_test/gtxt-010.40'
  make.exe[1]: Leaving directory `e:/_test/gtxt-010.40'

As it can be seen, no test of the testsuite fails. This is true
no matter if modified djdev203 or CVS djdev is used. This is also true
if I reconfigure the package from scratch or if I use the supplied
files from the package.


> Build process of gettext-0.10.40 fails in testsuite because it redefines
> gettext macros to something else.

I have checked all c files contained in the testsuite. This are:
tstgettext.c, tstngettext.c, plural-1-prg.c and setlocale.c.
tstgettext.c, plural-1-prg.c and setlocale.c either make no direct
reference to gettext macro at all or they only include libgnuintl.h.
Redefinition of gettext takes only place in libgnuintl.h and this is ok
and intentional. Please note that the DJGPP specific part in libgnuintl.h
is identical to the DJGPP specific part in installed libintl.h.
This is the specific quote from libgnuintl.h (libintl.h):

/* Resolve a platform specific conflict on DJGPP.  GNU gettext takes
   precedence over _conio_gettext.  */
#ifdef __DJGPP__
# undef gettext
# define gettext gettext
#endif

As it can be seen, gettext is unconditionally redefined to gettext
and this should not cause any harm in the testsuite. This unconditional
redefination of gettext is needed to make sure that GNU gettext *always*
takes precedence over BORLAND compatibility gettext (_conio_gettext)
no mather if conio.h is included before or after libintl.h (libgnuintl.h).
This has been a design goal when GNU gettext was ported and IMHO there
is no reason to change this.

The only c file that redefines gettext is tstngettext.c. In this file
the macro gettext is redefined to gettext__. This is the internal library
name of GNU gettext function in libintl.a. I have found no reason why this
unconditional redefinition should cause any harm to the testsuite.


> However, libgnuintl.h unconditionally defines them on DJGPP,
> while IMHO this is required iff conio.h has been previously defined.
> The tiny patch below allows building all programs in the testsuite.
[snip]
>  /* Resolve a platform specific conflict on DJGPP.  GNU gettext takes
>     precedence over _conio_gettext.  */
> -#ifdef __DJGPP__
> +#if defined __DJGPP__ && defined __dj_include_conio_h_
>  # undef gettext
>  # define gettext gettext

Yes, this is true. But unconditional redefinition generates no harm at all.
Introducing __dj_include_conio_h_ is not nice IMHO. IMHO there is no reason
at all to put in a GNU package such a DJGPP specific macro (__dj_include_conio_h_)
if we can achieve the same goal using a more unspecific macro like __DJGPP__.
IMHO, there is no difference if gettext is redefined to gettext all the time
(a word is simply replaced by exactely the same word and this should not produce
any harm, IMHO) or only if conio.h has been previously included by the source.
Please let me know if I am missing something here.

Anyway, I can not reproduce the testsuite failure you have reported. If there
exists such a failure, please elaborate a little bit more so I can reproduce it.

Regards,
Guerrero, Juan Manuel

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019