X-Authentication-Warning: acaxp6.physik.rwth-aachen.de: broeker owned process doing -bs Date: Tue, 1 Jul 2003 14:38:06 +0200 (MET DST) From: Hans-Bernhard Broeker To: Andris Pavenis cc: djgpp-workers AT delorie DOT com Subject: Re: conio.h bug? In-Reply-To: <200307011522.57814.pavenis@latnet.lv> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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 On Tue, 1 Jul 2003, Andris Pavenis wrote: > No. I haven't done anything with it. Did tests under Linux with gcc-3.4 > 20030630 (experimental) and gcc-3.3.1 20030627 (prerelease) Results are > below. So it's not a DJGPP only problem. ... except that DJGPP 2.03 would be probably be the only port of GCC to have a version of gettext() in its libc that conflicts with the builtin expectation of GCC. > gettext appears in file gcc/builtin-attrs.def for CVS at least beginning > with gcc-3.2 branch (haven't looked earlier). Ouch. What on earth did they think they'ld have to hardwire expectations about a non-standard function like gettext() into GCC for? This leaves us with two-and-a-half options, I think: 1) Patch the GCC port to DJGPP to remove this hardwired expectation (and try to get the GCC maintainers to accept that patch). 2) Add a patch for V2.03 conio.h to our GCC port's README that effectively brings it to the state of V2.04alpha (--> rename to _conio_gettext, and conditionally define gettext as a macro). 3) Take this issue as a reason to immediately release V2.04, and make all coming GCC ports require that. I'll leave it to you to judge which of these only counts as half an option ;-) -- Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de) Even if all the snow were burnt, ashes would remain.