Re: Same .m file: different results with different versions of Octave

[Judd Storrs]

On Sun, Apr 18, 2010 at 5:33 PM, Thomas Weber
<address@hidden> wrote:
> What makes you think it's not fixed? On my system, the code works as
> expected. Did you compile the upstream libc yourself? Have you verified
> that you are actually running GNU libc and not eglibc?

That's an interesting idea. No, I didn't compile the upstream libc. I
wasn't really anticipating that a bug that was fixed in 2005 and
included in glibc-2.3 would need a bleeding-edge compile in 2010, but
sure, I can do that. I have now attempted to compile the latest GNU
glibc from the git repository, but it looks like I'm my compiler can't
handle some of the inlines so I'll probably have to go update that,
too.

What version of libc are you using?

Based on what I've read online, I suspect the one installed on my
computers (lenny, karmic and lucid--all x86_64) is eglibc. All of
these computers have this problem. Is there an easy way to determine
whether eglibc or glibc is used? I can say that gnu_get_libc_version()
reports:

lenny: libc version 2.7
karmic: libc version 2.10.1
lucid: libc version 2.11.1

Do you think that compiling a new libc will fix the problem? Or is
this a problem with how debian/ubuntu built the packages? I don't see
any source code differences between the glibc and eglibc versions of
math/s_ctanh.c, math/s_ctanhf.c, math/s_ctanhl.c. None of those files
seem to have been touched since 2005 according to the repositories
which is why I question whether it was ever fixed in the first place.
The bug tracker never showed that tanh() was fixed, just an annotation
that something was done "upstream", which I interpret as FDLIBM and
then the bug was closed. So I don't see any verification that the bug
was ever fixed.


--judd