Re: Phasing out the separate EGLIBC source tree
On Sat, 2013-07-20 at 11:53 +0000, Joseph S. Myers wrote:
> 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.
Immediately I'll probably move libdfp development to github and then
work on glibc integration (round 2) when I have the time. The
intricacies of the build system will need to be very closely monitored
during migration.
Libdfp still lacks integration of the libbid backend (to make libdfp
work on x86), and I suspect that might be a prereq for glibc
integration. Tthe libdecnumber back end can be used (with some work)
for x86 support as well using DPD encoding on x86 rather than BID. This
was the original intention before Intel proposed the BID backend in
IEEE754-2008. As one might imagine, my employer will have little
interest in sponsoring me to do that work on company time.
In other words, x86 BID backend support for Libdfp could use a
maintainer/coder.
Ryan S. Arnold
IBM Linux Technology Center
Reply to: