This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Lukasz Majewski <lukma at denx dot de>
- Cc: <libc-alpha at sourceware dot org>, Paul Eggert <eggert at cs dot ucla dot edu>, Zack Weinberg <zackw at panix dot com>
- Date: Thu, 28 Mar 2019 16:31:44 +0000
- Subject: Re: [RFC 0/7] y2038: clock_settime rework to be Y2038 safe on 32bit systems
- References: <20190327085210.22019-1-lukma@denx.de> <alpine.DEB.2.21.1903271643480.3655@digraph.polyomino.org.uk> <20190328084356.627c0756@jawa>
On Thu, 28 Mar 2019, Lukasz Majewski wrote:
> FAIL: time/check-wrapper-headers
> ^^^ What are the "wrapper-headers"? Is this a different name
> for "installed" headers in glibc terms ?
Wrapper headers are the headers in include/ that are *not* installed but
wrap round the headers in other directories that *are* installed, so that
the glibc build process can find the right header from the source tree
rather than one that might have been installed by an older glibc version
and so is found by the compiler by default. For example, the installed
<time.h> comes from time/time.h in the glibc source tree; compilations in
subdirectories other than time/ don't search time/ for headers, so they
can only find time/time.h, rather than an older header like
/usr/include/time.h, because of the include/time.h wrapper that includes
<time/time.h> explicitly (and then adds some internal declarations).
Recent discussions and commits (which it is advisable to follow when
maintaining any large patch series over an extended period of time, to
keep that series up to date with such global changes) will show how we
agreed that all installed headers should have a wrapper, even if they are
not actually included from any source file outside the directory
containing the header, and how a test was added to verify this requirement
(after missing wrappers had been added). If you see a recently added test
failing with (or indeed without) your patches, the commit adding that
test, and surrounding discussions on libc-alpha, are the first place to
look to understand what is being tested.
> If I may ask:
>
> What is the workflow/setup for build-many-glibcs.py ?
The commit message for the commit that added the script includes
instructions, which are still current. If you only wish to test one
configuration (e.g. i686-gnu), naming that on the "compilers" and "glibcs"
commands will save a lot of time.
> and then
> ./src/glibc/scripts/build-many-glibcs.py -j8 . bot
You are unlikely to want to use it with "bot" unless you actually intend
to run your own bot that continuously builds and sends test logs to a
mailing list.
--
Joseph S. Myers
joseph@codesourcery.com