Status of remaining glibc/EGLIBC differences 2013-11-06
Here is the latest version of my list of differences between glibc and
EGLIBC, classified according to my expectations for what will happen
to them (whether, and to what extent, they will end up in glibc). We
are on track for EGLIBC 2.19 being the last EGLIBC release branch, as
previously discussed, with no merges from FSF glibc to EGLIBC trunk
happening after the 2.19 release (merges to EGLIBC release branches
are expected to continue for as long as the corresponding glibc
release branches are active, after which the EGLIBC repository, issue
tracker and website may be made read-only).
I believe other people are working on, or plan to work on, merging the
following changes to glibc.
1. Avoid __block identifier in installed headers (glibc bug 11157; I
think __glibc_reserved_block would meet the agreed convention now).
Meador Inge intends to work on this.
As far as I am aware, there are no plans to merge the following
changes to glibc, and so they will effectively go away as the separate
EGLIBC source tree is obsoleted. If you or your users are relying on
any of these changes, now would be a good time to (complete your
copyright assignment and) contribute them to glibc.
2. powerpc 8xx cache line workaround (r2503).
3. resolv.conf timestamp checks (note multiple followup fixes);
originated in a SUSE patch.
4. Option group support. Any work on of this should take into account
Steve Longerbeam's patches that didn't get checked in - that is,
start by locating the final versions of those patches, retesting
them, writing proper GNU ChangeLog entries for them and
resubmitting them. Then start from the resulting version of option
group support (probably one option group at a time). (See
<http://www.eglibc.org/archives/patches/msg01049.html> (8 Dec
2011).)
Note however that as I said at
<http://www.eglibc.org/archives/patches/msg01284.html> (28 June),
certain option groups do not make sense and should be removed.
5. SPE PIM functions (and associated testcases) from e500 port. They
could move into a separate library libspe (as they were in Aldy's
add-on). The implementations use some of the MPN functions, like
strtod does, so the library would naturally be a glibc add-on that
could pick up the relevant objects also used in libc.so, or the
symbols could be exported at GLIBC_PRIVATE from libc.so (I can see
possible use for these functions in libm in future as well). Such
an add-on might or might not be in the glibc repository.
6. Remaining parts of cross-localedef: that is, the separate build
system and a few miscellaneous changes in localedef that have no
significance as long as it's just built along with the glibc it's
linked against. (All the changes needed for localedef to generate
output for another system - everything needed for the output to be
system-independent apart from the endianness controlled by the
--big-endian / --little-endian options - are now in glibc, as are
those options. But you may need to build glibc for your build
system, matching the version being built for the system for which
you want to build locales, to use them.)
7. SH __fpscr_values. In general symbols should not be added to old
symbol versions, but there's a question here of whether actually
most or all SH glibc users are in fact using glibc with this patch
so it is part of the de facto ABI. See
<https://sourceware.org/ml/libc-alpha/2012-05/msg01988.html>.
8. A Linuxthreads manpage change. Insubstantial, but there's no glibc
git repository for Linuxthreads (it's never been converted from
CVS). It still appears to be the case that the man-pages project
does not have a manpage for pthread_mutex_init /
pthread_mutex_unlock (the one in question), and that Linuxthreads
is being used to provide a manpage for those functions by Ubuntu,
for example. I believe it is also the case that Linuxthreads is
still being used by GNU/kFreeBSD, so if that gets merged to glibc
then there may be a case for merging in the Linuxthreads history.
9. Installation of *_pic.a and associated .map files for use of
mklibs. Same question applies as for option groups about whether
this is still useful (the original use case of mklibs having been
for boot *floppies*).
10. Backwards compatibility with the install-bootstrap-headers
mechanism, and for the cross-test-wrapper variable name (the glibc
name is test-wrapper), and EGLIBC.cross-building and
EGLIBC.cross-testing documentation files and EGLIBC-specific
bug-reporting URL and pkgversion.
I am also not aware of any plans to transfer any relevant issues from
the EGLIBC issue tracker to the glibc tracker. I encourage people not
to file issues in the EGLIBC tracker any more, and anyone interested
to file issues for glibc corresponding to any EGLIBC issues that
actually apply to current glibc.
--
Joseph S. Myers
joseph@codesourcery.com
Reply to: