Re: supported version of glibc, workarround to gnulib and math constant module

[Bruno Haible]

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).

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!

> 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

Bruno


[1] http://people.redhat.com/drepper/tut1.ps