[patch/libstdc++-v3] export long double versions of "C" math library on more platforms

When libstdc++-v3 is built on a system running glibc-2.11 or newer, a 
libstdc++.so.6 is built not exporting anymore the long double versions of "C" 
math library.  For hppa-linux this is already taken care of.  The missing 
symbols were observed on arm-linux-gnueabi and mips*-linux-gnu builds.  Joseph 
S. Myers mentioned on #gcc that more platforms which did export these in the 
past should export these as well.  It's not clear if the old ARM ABI should 
export these as well.  If the patch is accepted, it should go to the active 
branches as well.

   Matthias
2010-06-12  Matthias Klose  <doko@ubuntu.com>

        * src/compatibility.cc: Export long double versions of "C" math
        library for arm-linux-gnueabi, m68k-linux-gnu (ColdFire),
        mips*-linux-gnu (o32 ABI), sh*-linux-gnu (not 32 bit).

On 06/12/2010 12:59 PM, Matthias Klose wrote:
> When libstdc++-v3 is built on a system running glibc-2.11 or newer, a
> libstdc++.so.6 is built not exporting anymore the long double versions
> of "C" math library.  For hppa-linux this is already taken care of. 
> The missing symbols were observed on arm-linux-gnueabi and
> mips*-linux-gnu builds.  Joseph S. Myers mentioned on #gcc that more
> platforms which did export these in the past should export these as
> well.  It's not clear if the old ARM ABI should export these as well. 
> If the patch is accepted, it should go to the active branches as well.
Thus, do I understand correctly that Joseph is OK with the arm bits of
your patch? Which kind of practical evidence do we have about m68k,
mips, and sh? At least, I would ask the maintainers to have a look...
can you do that?

Thanks,
Paolo.

On 06/15/2010 11:03 PM, Paolo Carlini wrote:
> On 06/12/2010 12:59 PM, Matthias Klose wrote:
>   
>> When libstdc++-v3 is built on a system running glibc-2.11 or newer, a
>> libstdc++.so.6 is built not exporting anymore the long double versions
>> of "C" math library.  For hppa-linux this is already taken care of. 
>> The missing symbols were observed on arm-linux-gnueabi and
>> mips*-linux-gnu builds.  Joseph S. Myers mentioned on #gcc that more
>> platforms which did export these in the past should export these as
>> well.  It's not clear if the old ARM ABI should export these as well. 
>> If the patch is accepted, it should go to the active branches as well.
>>     
> Thus, do I understand correctly that Joseph is OK with the arm bits of
> your patch? Which kind of practical evidence do we have about m68k,
> mips, and sh? At least, I would ask the maintainers to have a look...
> can you do that?
>   
Sorry, thus mips should be also fine. We are missing a minimum of data
about m68k and sh.

Paolo.

On Tue, 15 Jun 2010, Paolo Carlini wrote:

> On 06/12/2010 12:59 PM, Matthias Klose wrote:
> > When libstdc++-v3 is built on a system running glibc-2.11 or newer, a
> > libstdc++.so.6 is built not exporting anymore the long double versions
> > of "C" math library.  For hppa-linux this is already taken care of. 
> > The missing symbols were observed on arm-linux-gnueabi and
> > mips*-linux-gnu builds.  Joseph S. Myers mentioned on #gcc that more
> > platforms which did export these in the past should export these as
> > well.  It's not clear if the old ARM ABI should export these as well. 
> > If the patch is accepted, it should go to the active branches as well.
> Thus, do I understand correctly that Joseph is OK with the arm bits of
> your patch? Which kind of practical evidence do we have about m68k,
> mips, and sh? At least, I would ask the maintainers to have a look...
> can you do that?

The platforms in question - ARM EABI, MIPS o32, ColdFire, SH 32-bit - are 
the ones I listed on IRC as glibc platforms I know of where long double 
has the same representation as double.  I noted that I don't know whether 
this also applies to ARM old-ABI or SH64.  I don't see anything wrong with 
the preprocessor conditionals as representing the conditions I gave, 
although the ChangeLog reference to "not 32 bit" should be "32 bit" or 
"not 64 bit" (and as I said, I don't know whether that 32-bit restriction 
for SH is needed).

On 06/16/2010 12:45 AM, Joseph S. Myers wrote:
> The platforms in question - ARM EABI, MIPS o32, ColdFire, SH 32-bit - are
> the ones I listed on IRC as glibc platforms I know of where long double 
> has the same representation as double.  I noted that I don't know whether 
> this also applies to ARM old-ABI or SH64.  I don't see anything wrong with 
> the preprocessor conditionals as representing the conditions I gave, 
> although the ChangeLog reference to "not 32 bit" should be "32 bit" or 
> "not 64 bit" (and as I said, I don't know whether that 32-bit restriction 
> for SH is needed).
>   
Ok, the patch is OK with the small changes to the ChangeLog entry
indicated by Joseph.

Paolo.

On 16.06.2010 00:55, Paolo Carlini wrote:
> On 06/16/2010 12:45 AM, Joseph S. Myers wrote:
>> The platforms in question - ARM EABI, MIPS o32, ColdFire, SH 32-bit - are
>> the ones I listed on IRC as glibc platforms I know of where long double
>> has the same representation as double.  I noted that I don't know whether
>> this also applies to ARM old-ABI or SH64.  I don't see anything wrong with
>> the preprocessor conditionals as representing the conditions I gave,
>> although the ChangeLog reference to "not 32 bit" should be "32 bit" or
>> "not 64 bit" (and as I said, I don't know whether that 32-bit restriction
>> for SH is needed).
>>
> Ok, the patch is OK with the small changes to the ChangeLog entry
> indicated by Joseph.

Checked in with the suggested ChangeLog change. Will apply it to the branches 
later this week.

   Matthias

         * src/compatibility.cc: Export long double versions of "C" math
         library for arm-linux-gnueabi, m68k-linux-gnu (ColdFire),
         mips*-linux-gnu (o32 ABI), sh*-linux-gnu (32 bit).