Regenerating and updating upstream files
1. General
Some files checked in to the glibc repository are not maintained directly as source code in glibc. These are files imported verbatim from elsewhere, or generated files where we don't require the generator (for example, Autoconf for regenerating configure scripts) or its run-time dependencies (for example, Perl for regenerating C-translit.h) to be available when building glibc, or when regeneration of such a file is unusually slow.
The following come verbatim from upstream and should not be modified locally: scripts/config.guess, scripts/config.sub, scripts/install-sh, scripts/mkinstalldirs, scripts/move-if-change, manual/texinfo.tex. New versions may be updated verbatim from their upstream sources (in the case of manual/texinfo.tex, it may also be necessary to remove trailing whitespace).
The following license texts also come verbatim from upstream: COPYING, COPYING.LIB, manual/fdl-1.3.texi, manual/lgpl-2.1.texi. Any license changes should be discussed by the FSF-appointed maintainers (the project stewards) and the FSF.
configure scripts, including fragments in many subdirectories, are generated by autoconf. All should be generated using the same autoconf version (currently 2.72).
When regenerating glibc's configure you can simply run autoconf from the top-level directory.
When regenerating a port's configure you can run autoconf -I<path to glibc src> from the directory that contains the port's configure.ac fragment. Alternatively you can run autoconf /path/to/ports/configure.ac > /path/to/ports/configure from the top-level glibc directory.
- Bulk regeneration can be done from the top-level glibc source directory with:
for i in `find -L . -name 'configure.ac'`; do echo "touch $i; autoconf -I. $i > ${i%.ac}"; done;
locale/programs/charmap-kw.h and locale/programs/locfile-kw.h are generated by gperf when locale keywords are added. You should not have to update these manually. When the header files are out of date the build runs gperf automatically and this would be part of any submitted change.
INSTALL is generated by makeinfo; run rm $srcdir/INSTALL; make INSTALL to regenerate it (from the object directory). Currently we use texinfo version 7.0.3.
po/libc.pot is generated by gettext. To regenerate it, run the following from the root of the object directory:
make -r PARALLELMFLAGS="" -C <path to glibc srcdir>/po objdir=`pwd` libc.pot
po/*.po are maintained upstream by the translation teams and should not be modified locally. New versions may be found at the Translation Project site.
ABI baselines exist for each machine as *.abilist files within the machine directories. Run "make check-abi" for your architecture/ABI, make sure any changes to the ABI baselines are desirable and update the baselines using "make update-abi update-abi-config=REGEXP" with REGEXP being taken from the existing baselines.
When generating ABI baselines from scratch you must create empty *.abilist files in the source tree and those will act as your initial baseline. All of the ABI tests will fail but they will generate *.symlist files in the build directory which you can copy, edit, and verify, eventually replacing your *.abilist files as the final baselines. You will be comparing against as many past releases as possible to ensure the ABI is correct.
Some files come from gettext, libidn or GMP upstream but may also be changed locally in glibc. The procedures for updating these files locally are not well-documented and FSF approval may sometimes be needed to use a newer version under LGPLv2.1+. See https://sourceware.org/glibc/wiki/SharedSourceFiles
2. Unicode Support
As of the addition of Unicode 7.0.0 support, the following files are autogenerated from Unicode data sources:
localedata/locales/translit_*
localedata/charmaps/UTF-8
and localedata/locales/i18n,
The following will regenerate those files:
make -C <path to glibc srcdir>/localedata/unicode-gen all make -C <path to glibc srcdir>/localedata/unicode-gen install
The file locale/C-translit.h is generated from locale/C-translit.h.in. Enter the build directory and execute:
make -C <path to glibc src>/locale objdir=`pwd` C-translit.h
You may need to initially touch C-translit.h.in to trigger the update.
Upstream unicode files are synchronized with upstream unicode releases, see the shared source listing.
3. ISO 14651 Support for Collation
The ISO 14651 support in localedata/locales/iso14651_t1_common is taken from the published tables for the standard and then manipulated in order to avoid lowercase and uppercase overlap in the LATIN script range. The regeneration of this data file is very difficult, time consuming and error prone and we hope to make this better. If you need to update this from upstream sources then you need expert advice and reach out to the list.
4. Math files
See the Math section of the manual for some background details.
4.1. libm-test-ulps
This base line file can be semi-automatically updated. You can do either of the following:
Run make regen-ulps to merge the existing file with all new test results. Copy the resulting NewUlps file to the target ULPs file as indicated by the printed instructions.
Run a specific tests (test-float, test-double, etc.) with the -u flag (e.g. ./testrun.sh math/test-double -u; see Testing/Builds for more details). This will generate a file called ULPs which you can manually merge into the existing libm-test-ulps file. Then run gen-libm-test.pl -n -u FILE to produce a NewUlps which is the new sorted version of libm-test-ulps.
In either case, you will need to watch out for:
Old test results. The automatic steps will merge new stuff with the existing results, but won't trim out old stuff. Normally you'd truncate the libm-test-ulps (or just delete the results for the specific test/function you're updating) before automatically generating it, and then review the final diff to make sure nothing unusual crops up.
- ULPs don't automatically shrink, just grow. If the new ULPs results are larger than the previously recorded values, the test results will be updated to reflect the new value. But if the ULPs results are smaller, the old test results are used instead. The same truncation method (see "Old test results" above) should help here.