On 17 Mar 2006 22:44:37 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > Mark Mitchell <[EMAIL PROTECTED]> 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. Richard.
