[commit] Fix ENABLE_NLS; Was .... use ../intl/ when present

[Andrew Cagney]

Hello,

First lets address the technical problem:

[Several days scrounging up and installing a FreeBSD m/c, 10 minutes 
writing a patch, and then another day testing it later ...]

I've also committed the attached.  It fixes a problem where ENABLE_NLS 
was being set when there was no "nls".

This time I've regenerated both the relevant gdb and binutils configures 
(where applicable using autoconf-2.13 per Ian's recommendation).

This time I've also built things per the attached table (using CVS, not 
a snapshot - more on that latter):

                PPC-GNU/Linux    FreeBSD-4.9
gdb-default        built           built
gdb-disable        built           built
gdb-enable         built           built
bfd-default        built          [msgfmt]
bfd-disable        built          [msgfmt]
bfd-enable         built           built

Notes:

PPC-GNU/Linux: Has a full gettext installation
FreeBSD-4.9: Doesn't.
gdb-*: GDB from CVS with attach patch
bfd-*: BINUTILS from CVS with attached patch
*-default: Straight out-of-box config/build
*-disable: Configured with --disable-nls
*-enable: Configured with --enable-nls

And finally, [msgfmt]: BFD barfed vis:
   make  all-recursive
   Making all in doc
   Making all in po
   file=/home/cygnus/cagney/BINUTILS/src/bfd/po/`echo fr | sed 
's,.*/,,'`.gmo  && rm -f $file && PATH=../src:$PATH msgfmt -o $file 
/home/cygnus/cagney/BINUTILS/src/bfd/po/fr.po
   msgfmt: not found
   *** Error code 127
   Stop in /home/cagney/BINUTILS/native/bfd/po.

As you can see GDB is building fine out of CVS.  BINUTILS on the other 
hand has trouble - it can only be built if msgfmt is installed (intl/ 
doesn't include this).  (Mark, suspecting something like this is why I 
asked that you use a snapshot - it should at least avoid that).

Now the logistic, or as some would describe it, political problem:

Mark Kettenis wrote:

>    The attached should fix a further problem - it was appending NONE as the 
>    catalog suffix.  Again tested on a system with installed gettext, and 
>    with --disable-nls (which isn't very useful).
> 
>    If people still encounter problems can they please include a few details 
>    such as the broken Makefile.  Otherwize I'm put in a situtation where 
>    I'm flying blind :-(

Per above, 10 minutes with a machine with the bug and a trivial tweak 
fixes the problem, and gets GDB building when binutils can't.

> Sorry Andrew, but this just helps a tiny little bit.  I'm sorry that I
> didn't provide more details, but I wasn't asking you to fix
> gettext.m4.  The problem here is that gettext.m4 was only designed to
> be used with an included intl/ subdirectory.  Therefore it does only a
> halfhearted check for an external intl/ and never ever disables
> internationalization unless you explicitly ask for it by specifying
> --disable-nls on the command line.  Removing intl/ was a mistake that
> did go unnoticed because of limitations of cvs.  When I first noticed
> the problem in december, I looked at whether we could fix gettext.m4.
> My assessment was that it wasn't easy and that it would be much easier
> to simply bring back intl/.  Our motivation for removing intl/ was
> that it somethings caused build problems, but we never analyzed those
> problems quite in detail (my suspicion is that this case is similar to
> the ncurses breakage; compiler searching /usr/local/include but the
> linker not searching /usr/local/lib or the other way around).
> 
> The proper way to fix this seems to be to bring over intl/ from GCC.
> The wish has been expressed several times on the gdb and binutils
> mailing lists, and I haven't seen any objections.  I'll commit myself
> to doing the work in march if you'll bring back intl/ in the meantime.

GDB got out of the business of using src/intl/ for a very simple reason, 
it was broken, un-maintained, and out-of-date (sound familar?  think 
src/dejagnu/ :-).

The decision made was to drop the existing src/intl/ (known to not build 
on several systems) and instead have GDB use an external gettext when 
available, and none otherwise.  Once GDB's i18ed (at the time 0% of GDB 
was i18n) and once intl/ was up-to-date the decision was to be reviewed. 
  This way we could ensure that GDB at least built on all systems.

While regrettable, it's not unsurprising that the decision's 
implementation had a few hiccups - after all the bulk of developers 
building GDB on systems with a bundled gettext the relevant code paths 
went untested.  Oops!

The key thing to note though is that such teething problems don't 
necessarily imply the immediate need to reverse that decision.  In fact 
doing so just re-arranges the deck chairs on the titanic - it might fix 
some systems but sure as hell doesn't fix others (see above, it can't 
fix FreeBSD built from CVS).

Contrast that to the action taken - by instead fixing the configury 
problems we've now [hopefully] got a GDB that builds builds on any 
system that lacks i18n (be it a snapshot or from CVS).

Andrew

PS: It's worth nothing that the proposal to upgrade src/intl/ is 
currently blocked by BINUTILS.  It can't be scheduled until after the 
next BINUTILS has branched.

PPS: Perhaps BINUTILS turn to re-think their position - "focus on the 
core competencies" and get out of the business of maintaining intl/.

PPPS: Systems such as FreeBSD eventually end up installing gettext as 
part of the ports/packages install process.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: diffs
URL: <https://sourceware.org/pipermail/binutils/attachments/20050131/06426fbc/attachment.ksh>