Hi, Jan Beulich writes: > May I please ask that a change like this come with a real description? The > ChangeLog entries certainly describe - purely mechanically - what is done > to the files, but to be honest I cannot really read out of the (large) > patch what the overall behavioral change is. Hopefully, none. Building without gettext in-tree or on the system should result in a working build with no localization, with gettext in-tree and on the system it should result in the usage of the system gettext, with gettext on the tree but _not_ on the system, it should result in a new (static) copy being built and linked into the tools, with working localization, and with no gettext in tree but in system (either in libc or in libintl) should result in a localized build using the system gettext facilities. The behavior for the in-tree but also on the system case (e.g. building with gettext in-tree on a GNU system) can be overridden with --with-included-gettext (which is a configure flag for gettext-runtime, and was a configure flag for intl/ before that). I've updated the commit message to add: > This patch updates gettext.m4 and related .m4 files and adds > gettext-runtime as a gmp/mpfr/... style host library, allowing newer > libintl to be used. > > This patch /does not/ add build-time tools required for > internationalizing (msgfmt et al), instead, it just updates the > runtime library. The result should be a distribution that acts > exactly the same when a copy of gettext is present, and disables > internationalization otherwise. > > There should be no changes in behavior when gettext is included > in-tree. When gettext is not included in tree, nor available on the > system, the programs will be built without localization. I hope this clarifies it. Would you like to see anything else in the description? Apologies for not adding context initially, I've been finishing this patch on-and-off for a long time (due to being quite busy), and so, what context is and isn't present (and what is and isn't known) got lost on me. Jan Beulich writes: > I'm therefore only getting the impression that you make gettext > 0.22(?) a prereq to building binutils and gdb. No, it's still optional. 0.22 is only a prerequisite for building in-tree, otherwise, quite old versions of gettext from the system should work, too. > Which in turn may make it impossible to (easily) build either on older > systems (it would certainly limit [remove?] my ability to test 32-bit > builds of binutils, as the newer distros I use all only come in 64-bit > flavors; there may be ways to configure as 32-bit, but past experience > has shown that such is potentially fragile / only partially > functioning). A localized build should work fine on a 32-bit system (ISTR Iain testing 32-bit targets by dropping a copy of gettext in-tree, but don't quote me on that). A build of binutils or gdb (or gcc, for that matter) which has a gettext/ tree included in the toplevel should behave as it does today. In any case, non-localized builds should always work. -- Arsen Arsenović