[PATCH] intl: reintroduce unintentionally disabled optimization

[Joseph Myers]

On Mon, 22 Feb 2016, Florian Weimer wrote:

> * Dmitry V. Levin:
> 
> >> Is config.h.in regenerated by autoreconf and similar tools?
> >
> > No, it's supported manually and therefore permanently out of sync.
> > For example,
> >
> > $ grep -i strerror config.h.in 
> > #undef	HAVE_STRERROR
> > #define	HAVE_STRERROR	1
> > find -name configure.ac | xargs grep -i strerror | wc -l
> > 0
> 
> Can we have autoreconf automatically generate config.h.in, like other
> GNU projects do?

The complications with that are (a) manually written code in there such as 
the #error calls and macros present for the benefit of code shared with 
other projects (e.g. asserting that glibc has certain functionality, when 
it's not possible to test for it at configure time when building glibc), 
(b) macros present only for sysdeps configure scripts and (c) conditionals 
around some of the macros.

Now, we might formulate a strategy for eliminating such problem cases, 
which could be done incrementally.  For example:

* Some of the macros aren't actually used anywhere and could just be 
removed.

* Manually written content that doesn't actually depend on configure tests 
might better go in include/libc-symbols.h, which is what's implicitly 
preincluded via CPPFLAGS (except for compilations for the build system, 
which include config.h directly - only really OK if there are no conflicts 
between testing for given features on the two systems).

* Are the _LIBC conditionals actually needed?

* Bug 14068 discusses the issue of separation between machine-dependent 
and machine-independent pieces, though I don't know how existing auto* 
features might best be used to generate and use multiple config.h.in 
fragments.  Anything that is an architecture / OS property not depending 
on compiler / binutils features tested at configure time can go in sysdeps 
headers instead of config.h.in (except for the cases that are for use in 
conditionals in shlib-versions files, to avoid needing extra sysdeps 
directories in those cases).

* <https://sourceware.org/ml/libc-alpha/2014-06/msg00784.html> deals with 
the USE_REGPARMS / internal_function issue.

* Any HAVE_* needed only in certain directories for shared code could be 
defined in those directories (cf. timezone/Makefile defining various 
macros to configure the code from tzcode).

-- 
Joseph S. Myers
joseph@codesourcery.com