Re: library bug?
>>>>> "Alan" == Alan Eugene Davis <firstname.lastname@example.org> writes:
Alan> After successfully compiling ELF binaries for PROJ.4 (map projections
Alan> conversion package), I followed these instructions to test for
Alan> "braindead" libraries, which failed. I think this may be of some
Alan> interest to the maintainers of the libraries. I must admit, I haven't
Alan> a clue which library is involved.
O.K. here's the libc (and libm) maintainer :)
>> Check /usr/include/math.h for prototype of hypot. If missing it is
>> probably not in libm.a and it is necessary to use supplied version.
Alan> I think hypot was present.
You are right, I know for sure :-)
>> make install HYPOT='$L(hypot.o)'
>> make install HYPOT='$L(hypot.o)' STRTOD='$L(strtod.o)'
>> To check for brain damaged versions of strtod try the following after
>> using the local system's version (default):
>> proj +proj=poly +ellps=clrk66 +no_defs <<EOF
Wow, use brain damaged (read non POSIX compliant) flags to test for non-ANSI strtod ?
>> 3.5 33.25
>> 3d30 33d15
>> Both geographic coordinates should produce the same cartesian result.
>> If not, then it is almost a certainty that libc.a has a version modified
>> to accept d | D as an alternative to e | E. This "extension" to ANSI
>> specifications causes untold grief. Use the ANSI compliant GNU version
Alan> The values I got were:
Alan> 326186.98 3685744.37
Alan> 326725.05 3667246.41
Alan> Close, but no cigar.
What results did you get with the included ANSI compliant GNU version?
I suspect there are some numeric problems. From the top of my head,
these geodetic conversions are numerically bad behaved.
Alan> I am running GCC 2.7.2
Alan> libc5-dev 5.2.18-1
Alan> libc5 5.2.18-1
Alan> Also installed on the system is libc4 4.6.27-11, but I don't have the
Alan> a.out compiler.
Alan> I haven't been able to quite comprehend the remedy, but a
Alan> local "ANSI compliant GNU version" of the offending function is
Alan> included with the source code.
The source file strtol.c carries a GNU copyright notice, if this
doesn't convince you, here is a small test program, proving that the
differences you are complaining about, are not strtod's fault.
-------------------------- it.c ---------------------------
main (int argc, char **argv)
while ( scanf("%s", buf) == 1 )
printf("hypot(0.0, strtod(\"%s\")) == %g\n",
buf, hypot(0.0, strtod(buf,NULL)));
bora:~/tmp: gcc -Wall -O2 -lm -o it it.c
bora:~/tmp: it <<EOF
12.34 12.34e56 12.34d56
strtod("12.34") == 12.34
strtod("12.34e56") == 1.234e+57
strtod("12.34d56") == 12.34
bora:~/tmp: ldd it
libm.so.5 => /lib/libm.so.5.0.5
libc.so.5 => /lib/libc.so.5.2.18
BTW: This is for the implemnetor of proj: there is a nice GNU tool
called autoconf, you can use it to create a confguire script that
finds out if the system your program is compiled on is "brain
damaged"<grrr>, better yet you can use it to write portable code.
mailto:email@example.com // programmer/admin for hire
firstname.lastname@example.org \\ Opinions are strictly my own,
voice: +49-251-8619-99 \\ everything else is GPLed
- library bug?
- From: Alan Eugene Davis <email@example.com>