This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] intl: reintroduce unintentionally disabled optimization
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Florian Weimer <fw at deneb dot enyo dot de>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 22 Feb 2016 18:25:17 +0000
- Subject: Re: [PATCH] intl: reintroduce unintentionally disabled optimization
- Authentication-results: sourceware.org; auth=none
- References: <20160124000754 dot GA27321 at altlinux dot org> <m27fizbc0k dot fsf at linux-m68k dot org> <878u2dx6x5 dot fsf at mid dot deneb dot enyo dot de> <20160222130637 dot GB6033 at altlinux dot org> <874md096x0 dot fsf at mid dot deneb dot enyo dot de>
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
* 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