Re: [patches] DFP for EGLIBC

[Steven Munroe <munroesj@xxxxxxxxxx>]

H.J. Lu wrote:
> 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. 
>
> My concern is 2 source trees without a master copy and 2 different
> licenses.
>
>   
>>> 2. Include the full libbid in libgcc. We will make libgcc much bigger
>>> and we have to deal with ABI issue for libgcc_s.so.
>>> 3. Build/install libbid.a and libbid_pic.a for gcc. eglibc can
>>> just use them in the build.
>>>       
>> This is an interesting suggestion, but I'm not enthusiastic about
>> having the two DFP representations use different approaches for EGLIBC
>> integration.  I'd like to have the two implementations be as parallel
>> as possible.
>>     
>
> It can be done for libdecNumber also.
>   
The precedent for libdfp and libdecnumber have already been set.
copyrights and licences have been negotiated with the communities
involved. I see no need to change this. It seem best if libbid changes
to fit into the established framework.