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.