g++ lib problem

g++ lib problem

[Frans Meulenbroeks]

Hi,

I was trying to port a program that used asinl etc. but apparently
asinl is not in our env.
However if I look at
~/oe/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/include/c++/cmath I
see around line 123

  inline long double
  asin(long double __x)
  { return __builtin_asinl(__x); }

questions:
shouldn't this have been a double asin? (probably not too important as
the result will be casted)
and if asin is long double, then why is there no asinl?
normally it is

double asin(double x);
long double asinl(long double x);

guess this is something in the way our libs are generated, but I could
not find the proper way to fix it.

Anyone a suggestion?

Frans.

Re: g++ lib problem

[Khem Raj]

On Thu, Mar 12, 2009 at 2:52 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> Hi,
>
> I was trying to port a program that used asinl etc. but apparently
> asinl is not in our env.

Did you link with -lm ?

Re: g++ lib problem

[Frans Meulenbroeks]

2009/3/12 Khem Raj <raj.khem@gmail.com>:
> On Thu, Mar 12, 2009 at 2:52 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> Hi,
>>
>> I was trying to port a program that used asinl etc. but apparently
>> asinl is not in our env.
>
> Did you link with -lm ?
>
It didn't get that far. the compiler already complains about asinl not found.
On opensuse this compiles ok. Apparently when generating the c++ lib
or header it is decided that the function is not there, although the
header file links asin to __builtin__asinl or something like that).

Frans.

Re: g++ lib problem

[Khem Raj]

On Thu, Mar 12, 2009 at 1:34 PM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2009/3/12 Khem Raj <raj.khem@gmail.com>:
>> On Thu, Mar 12, 2009 at 2:52 AM, Frans Meulenbroeks
>> <fransmeulenbroeks@gmail.com> wrote:
>>> Hi,
>>>
>>> I was trying to port a program that used asinl etc. but apparently
>>> asinl is not in our env.
>>
>> Did you link with -lm ?
>>
> It didn't get that far. the compiler already complains about asinl not found.
> On opensuse this compiles ok. Apparently when generating the c++ lib
> or header it is decided that the function is not there, although the
> header file links asin to __builtin__asinl or something like that).
>

I see it gets it from libm but g++ specifiies -lm for you where as gcc
does not. I think the problem is that ARM have same precision for
double and long double so glibc defines __NO_LONG_DOUBLE_MATH for ARM
as a result the prototypes for the *l functions are not emitted into
math.h. Although in glibc they are aliases for the corresponding
double functions I dont know why they are not exported in math.h too.
may be they want to make it difficult for people to use them on
platforms where they are not really different then double
counterparts.

So if you use gcc -lm it works because gcc does not barf on missing
prototypes but it wont compile with g++ because g++ does not find the
prototype for asinl in math.h and gives error.

> Frans.
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: g++ lib problem

[Frans Meulenbroeks]

2009/3/12 Khem Raj <raj.khem@gmail.com>:
[...]
>
> I see it gets it from libm but g++ specifiies -lm for you where as gcc
> does not. I think the problem is that ARM have same precision for
> double and long double so glibc defines __NO_LONG_DOUBLE_MATH for ARM
> as a result the prototypes for the *l functions are not emitted into
> math.h. Although in glibc they are aliases for the corresponding
[...]

Khem,

Thanks for the explanation.
Should we change the glibc package to resolve this?

Frans

Re: g++ lib problem

[Khem Raj]

On Fri, Mar 13, 2009 at 8:15 AM, Frans Meulenbroeks
<fransmeulenbroeks@gmail.com> wrote:
> 2009/3/12 Khem Raj <raj.khem@gmail.com>:
> [...]
>>
>> I see it gets it from libm but g++ specifiies -lm for you where as gcc
>> does not. I think the problem is that ARM have same precision for
>> double and long double so glibc defines __NO_LONG_DOUBLE_MATH for ARM
>> as a result the prototypes for the *l functions are not emitted into
>> math.h. Although in glibc they are aliases for the corresponding
> [...]
>
> Khem,
>
> Thanks for the explanation.
> Should we change the glibc package to resolve this?
>

hmmm IMO I think you should fix the application to not ask for long
double functions on platforms where long double is
not different than double and fixing glibc could be ok too. Care for a patch :)
> Frans
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: g++ lib problem

[Frans Meulenbroeks]

True but why not add long double function prototypes to glibc as we have them.
Might save someone some headache later on.

For my specific problem:
In the package I added a patch for this, and I raised the issue with
the author of the sw who informed me that the long double accuracy was
not really needed, so guess the problem will be gone in the next
release anyway.

Frans

2009/3/13 Khem Raj <raj.khem@gmail.com>:
> On Fri, Mar 13, 2009 at 8:15 AM, Frans Meulenbroeks
> <fransmeulenbroeks@gmail.com> wrote:
>> 2009/3/12 Khem Raj <raj.khem@gmail.com>:
>> [...]
>>>
>>> I see it gets it from libm but g++ specifiies -lm for you where as gcc
>>> does not. I think the problem is that ARM have same precision for
>>> double and long double so glibc defines __NO_LONG_DOUBLE_MATH for ARM
>>> as a result the prototypes for the *l functions are not emitted into
>>> math.h. Although in glibc they are aliases for the corresponding
>> [...]
>>
>> Khem,
>>
>> Thanks for the explanation.
>> Should we change the glibc package to resolve this?
>>
>
> hmmm IMO I think you should fix the application to not ask for long
> double functions on platforms where long double is
> not different than double and fixing glibc could be ok too. Care for a patch :)
>> Frans
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>