Re: [patches] DFP for EGLIBC

[Jim Blandy <jimb@xxxxxxxxxxxxxxxx>]

"H.J. Lu" <hjl at lucon.org> writes:
> On Wed, Oct 31, 2007 at 05:23:11PM -0700, Jim Blandy wrote:
>> 
>> "H.J. Lu" <hjl at lucon.org> writes:
>> > On Tue, Oct 30, 2007 at 10:31:14AM -0700, Jim Blandy wrote:
>> >> 
>> >> Hi, Peter and Ryan!  How is the decimal floating point work coming
>> >> along?  Do you have a timeline for the submission process at this
>> >> point?
>> >
>> > Speaking of DFP, I am investigating DFP functions optimized for
>> > BID. libbid in gcc includes a complete set of DFP functions optimized
>> > for BID. But only those functions used by gcc intrinsics are compiled
>> > in gcc. I'd like to use the full libbid in eglibc. We have 3 choices:
>> >
>> > 1. Include libbid source in eglibc. We will run into license issue,
>> > LPGL vs. GPL, as well as duplicated source trees.
>> 
>> Is there any chance libbid could be re-licensed as we recommended for
>> libdfp?
>> 
>> http://www.eglibc.org/archives/patches/msg00338.html
>> 
>> It seems to me that duplicated source trees are less than ideal, but
>> if we designate one copy to be the master it doesn't seem like a
>> deal-breaker.  What has your experience been with similar
>> arrangements, like the one between gcc/config/soft-fp and
>> eglibc/soft-fp?
>
> Intel disclaimed the copyright of libbid when it was contributed to
> gcc. It is up to FSF to re-release it under LGPL. 

All right --- that seems like something that we can work on, then.

> My concern is 2 source trees without a master copy and 2 different
> licenses.

Certainly, there must be a designated master copy.  Ideally, soft-fp,
IBM's DFP stuff, and Intel's DFP stuff would all be following the same
master/slave conventions, and have the same license.

In the long run, I think we want to see libdfp.so as the only
installed .so, absorbing libdecnumber.so.  libdecnumber.so doesn't
implement an interface that we want people to be using; they should
use the interface described in TR24732.  (I gather libdecnumber needs
to stay separate at the source level, but we don't need to install it
that way.)  Then, libdfp will have BID and DPD sysdep directories used
as appropriate.

But, to be clear; I'm very new to the whole DFP picture, so I'm more
concerned with arriving at a practical consensus amongst the people
who know the bits than I am with any particular solution.