This is the mail archive of the
mailing list for the GCC project.
Re: FSF Policy re. inclusion of source code from other projects in GCC
On 17 Mar 2006 22:44:37 +0100, Gabriel Dos Reis
> Mark Mitchell <firstname.lastname@example.org> writes:
> | >> Because RMS has approved the use of GLIBC's software floating-point code
> | >> in GCC's runtime libraries, using GPL + exception, the correct thing for
> | >> Joseph Myers to do with his recent patch is to mark those files as not
> | >> part of GCC, but rather as part of GLIBC, and adjust the copyright
> | >> notice to be GPL + exception. Joseph should also document (in a README
> | >> or similar) that these files are not to be changed, except by import
> | >> from upstream GLIBC.
> | >
> | > Do I understand this correctly that the upstream GLIBC versions of the
> | > files will get their license changed, or will this happen only in the GCC
> | > copy?
> | Only in the GCC copy.
> | I don't understand enough about libgcc-math to know what should happen
> | there; I don't even know what bits of GLIBC you used. RMS has given
> | explicit permission to use GPL + exception for the software
> | floating-point emulation code, but not for any other part of GLIBC.
> I am confused. My interest in libgcc-math is that it helps solve
> thorny issues with libstdc++-v3 and my expectation is that we can make
> modification to libgcc-math so that we can't advantage of it. Now, I
> understand that we cannot make modification to libgcc-math without
> modifying GLIBC? Is that correct.
I understand it in the way that we should modify the imported parts
upstream (or not), while we can for sure add glues and wrappers or
other thinks to libgcc-math. So this discussion only affects flt-32
and dbl-64 directories. I don't think this will make the libstdc++-v3
issues impossible - maybe a little harder. If there will be a point where
a true fork is inevitable, we can politely ask again.