Re: [patches] DFP for EGLIBC

["H.J. Lu" <hjl@xxxxxxxxx>]

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.


H.J.