[Patches] EGLIBC 2.19 set up (last release branch), EGLIBC trunk now closed

["Joseph S. Myers" <joseph@xxxxxxxxxxxxxxxx>]

I have now set up the EGLIBC 2.19 branch.  This is the last EGLIBC
release branch; unless you are relying on changes in EGLIBC relative
to glibc that have not been merged to glibc, you are advised to use
glibc 2.19 branch instead of EGLIBC 2.19 branch.  If you are relying
on such changes, listed below, you should plan to contribute such
features to glibc so you can cease using EGLIBC; EGLIBC trunk will no
longer be maintained.  Occasional merges to EGLIBC release branches
will continue while glibc 2.19 or older branches are still open.

Note that 2.19 has the version of the e500 port contributed to glibc,
with some incompatibilities with the version previously in EGLIBC, as
detailed at <http://www.eglibc.org/archives/patches/msg01291.html>.


1. powerpc 8xx cache line workaround (r2503).

2. resolv.conf timestamp checks (note multiple followup fixes);
   originated in a SUSE patch.

3. 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.

4. 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.

5. 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.)

6. 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>.

7. 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.

8. 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*).

9. 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@xxxxxxxxxxxxxxxx
_______________________________________________
Patches mailing list
Patches@xxxxxxxxxx
http://eglibc.org/cgi-bin/mailman/listinfo/patches