Phasing out the separate EGLIBC source tree
Following up on discussions in another thread, here is the plan I propose
for phasing out the separate EGLIBC source tree so that all glibc
development for embedded systems goes directly in the main FSF glibc git
tree.
I propose the goal that 2.19, in about six months' time, is the last
EGLIBC release branch, so after than point no more merges from FSF glibc
would be made to EGLIBC trunk. Merges would continue to be made to EGLIBC
release branches for as long as the corresponding FSF glibc branches are
active. After they cease to be active, the repository, issue tracker and
website might be made read-only.
As a consequence of making the repository read-only, libdfp development
would need to move elsewhere - I suggest properly integrating it into
glibc, so that glibc builds for relevant architectures automatically
build, test and install the libdfp library and include the relevant header
support. Given that fegetenv/fesetenv/feholdexcept/feupdateenv should
include the decimal rounding mode in the saved/restored environment (and
draft TS 18661 adds fegetmode/fesetmode to the functions that should
handle it), I don't think a completely separately built library is an
entirely satisfactory approach for this functionality anyway.
Regarding the specific differences between glibc and EGLIBC, as listed in
<http://www.eglibc.org/archives/patches/msg01292.html>, my plans are as
follows. If I complete merging the patches I intend to work on merging,
I'd consider that sufficient to cease merges from FSF glibc after 2.19.
So distributors to whom any of the other patches may be relevant should be
(completing their copyright assignments and) working on merging those
patches to glibc themselves.
1. powerpc 8xx cache line workaround: no plans to merge.
2. Robustness for ldd with non-bash shells: no plans to merge, but have
asked the submitter of a more general glibc patch to chase up their
assignment status with the FSF, so hopefully that will get in eventually.
3. Avoid __block identifier: no plans to merge, but Meador Inge has
expressed an interest.
4. resolv.conf timestamp checks: no plans to merge.
5. Option group support: no plans to merge.
6. e500 port: I plan to rework this for glibc so it follows the ABI of the
soft-float powerpc port and submit in that form, with the ABI consequences
previously described (so 2.18 would be the last EGLIBC release branch
using the old ABI for this port).
7. Making --disable-versioning work: I plan to revert all these changes
from EGLIBC and remove the --disable-versioning and --enable-oldest-abi
options completely from glibc, as discussed on libc-alpha.
8. Cross-localedef: I plan to merge the options for localedef to generate
locales for other systems (*not* anything for standalone build or building
any form of cross-localedef binary from a glibc build tree).
9. SH __fpscr_values: no plans to merge.
10. bits/predefs.h: I plan to implement an appropriate GCC feature for GCC
4.9 so that GCC can predefine these macros when the command-line options
to GCC indicate the appropriate intent (and glibc will then defer to GCC),
but without any attempt to conditionally not define these macros in some
cases with older GCC.
11. ColdFire MMAP2_PAGE_SHIFT: once glibc 2.18 has branched I'll commit
the libc patch and ping the ports one.
12. Linuxthreads manpage change: no plans to merge.
13. Installation of files for mklibs: no plans to merge.
14. Extra test debug/tst-backtrace6: I plan to file a bug in glibc
Bugzilla explaining the issue and with the testcase attached, then remove
it from EGLIBC.
I do not plan to copy any issues from the EGLIBC tracker to the glibc one;
people concerned about particular issues should file corresponding ones in
the glibc tracker as needed.
--
Joseph S. Myers
joseph@codesourcery.com
Reply to: