[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: supported version of glibc, workarround to gnulib and math constant
From: |
Bastien ROUCARIES |
Subject: |
Re: supported version of glibc, workarround to gnulib and math constant module |
Date: |
Fri, 2 Jul 2010 11:11:57 +0200 |
On Fri, Jul 2, 2010 at 2:01 AM, Bruno Haible <address@hidden> wrote:
> Hi Bastien,
>
>> I am trying to port harminv to gnulib.
>>
>> However this package has the following code in order to work arround a
>> weird bug in glibc 2.2.5. Do you support this lib ?
>>
>> If you use the complex clog function in a pure c program library than
>> link from another (C++) program, the program seems to crash from this
>> c++ program. It seems related to
>> a conflict between class clog of c++ and function clog. Upstream of
>> harminv use the following workarround:
>> #undef clog
>> #define clog my_clog
>>
>> static cmplx my_clog(cmplx z)
>> {
>> return (log(cabs(z)) + I * carg(z));
>> }
>>
>> Does this kind of workarround is suitable for gnulib ?
>
> I don't exactly understand what the problem/bug is. Ulrich Drepper claimed
> to have solved it already for glibc 2.1 ([1] page 35).
For sure it is surelly on older libc++, and surelly a transient
conflict. Not worth the effort.
> So far gnulib has no support for these complex functions, because they take
> arguments of type 'complex double', and not all compilers support this type.
> For those that don't, there is no substitute.
>
> But if you want to start extending gnulib in the direction of complex
> functions
> - assuming the type 'complex double', but fixing all other kinds of problems -
> you're welcome!
If you have some documented problem, i could give a try.
>> Another question do you accept a package a math constant like for
>> instance M_PI and other constant? It will be really useful for math
>> and physics program to get a resonnable loist of math constant by
>> default.
>
> I agree, it would be useful. We have a module 'math', which provides a
> substitute <math.h>, but so far, we have dealt with NAN and HUGE_VAL only.
> If you know portability problems for M_PI and other constants, please tell
> us or provide patches to
> doc/posix-headers/math.texi
> lib/math.in.h
> m4/math_h.m4
M_PI is defined under linux if _USE_BSD, __USE_XOPEN, __USE_GNU
A lot of portable scientific code use stuff like :
#ifndef M_E
#define M_E 2.71828182845904523536028747135 /* e */
#endif
#ifndef M_LOG2E
#define M_LOG2E 1.44269504088896340735992468100 /* log_2 (e) */
#endif
#ifndef M_LOG10E
#define M_LOG10E 0.43429448190325182765112891892 /* log_10 (e) */
#endif
Under mingw if only #ifndef __STRICT_ANSI__
And some constant are missing like M_TWOPI
Bastien
> Bruno
>
>
> [1] http://people.redhat.com/drepper/tut1.ps
>