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 [email protected] -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
