Date: Wed, 26 Apr 2000 06:59:08 -0400 (EDT) Message-Id: <200004261059.GAA23630@indy.delorie.com> From: Eli Zaretskii To: "Juan Manuel Guerrero" CC: djgpp-workers AT delorie DOT com In-reply-to: <1FCF05F5782@HRZ1.hrz.tu-darmstadt.de> (ST001906 AT HRZ1 DOT HRZ DOT TU-Darmstadt DOT De) Subject: Re: ANNOUNCE: DJGPP port of GNU Gettext 0.10.35 References: <1FCF05F5782 AT HRZ1 DOT hrz DOT tu-darmstadt DOT 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 Precedence: bulk > From: "Juan Manuel Guerrero" > Date: Tue, 25 Apr 2000 23:11:03 +0200 > > > If the problem is with gettext from conio.c, then I think this problem > > could be solved with less radical means. > > That is the reason. If you can show me a less radical solution it will be > seriously appreciated. > Unfortunately gettext.m4 always searches for gettext() in libc.a first. > For DJGPP this implies that gettext() defined in conio.h will be found > first. Of course this is the wrong gettext(). The right solution would be to modify gettext.m4 test so that it fails for DJGPP's own gettext. The easiest way to do that is to include conio.h; I expect this to cause GCC to fail the compilation due to different prototypes. (To be portable, this test will have to be preceded by an additional one, that checks whether conio.h is available.) I would suggest to submit such a change to gettext maintainer. However, the gettext maintainer does not have any sympathies for the DJGPP project, to say the least, so I'm not holding my breath for the inclusion of such a change. In any case, it will take time to get that change propagated through the other GNU packages. Therefore, I suggest a simpler band-aid in the meantime: force the configure script to fail that specific test, by including something like this in an appropriate file: nls_cv_force_use_gnu_gettext=yes The files where this could go are either the local config.site file, or the global config.site distributed with Bash. Another possibility would be to configure the packages with the option --with-included-gettext. > 1) Renaming gettext() to GetText(). Now the search for GetText() in libc.a > will fail and GetText() will be searched and found in libintl.a. The problem is that gettext in conio is a compatibility function, modeled after its Borland's namesake. > Emacs, nm and ld can be defined in config.site. I realized this to late. Why ``too late''? You can change this and upload a new beta. No harm was done.