[perl #34549] atan2() isn't IEEE compliant on OpenBSD/*BSD/Cygwin/Solaris

[Rolf Grossmann]

Andy Dougherty wrote:

> On Solaris 8, here's how it seems to work:
[...]

Wow, you figured it out. Great work.

> For gcc, the file values-Xa.o appears to be hard-wired in to the
> built-in specs.  The only way to change it appears to be to override it
> with a custom specs file.  Hmm.  That might not be too hard.  We just
> create a file (I'll call it 'parrot-gcc.specs') with the following two
> lines:
> 
>     *startfile_arch:
>     %{ansi:values-Xc.o%s}                   %{!ansi:values-xpg4.o%s}
> 
> and then add  -specs=parrot-gcc.specs to $linkflags.
> (if values-xi.o is available, that might be a better choice.)

I think xpg4 will be fine. Anything else will need to also figure out 
if we're building 32bit or 64bit binaries and adjust the path aswell.

> It's not *too* messy.  What do you think? 

I think it's great.

> (Hmm.  It might get messy
> for installation, however -- where do we put the specs file so that
> languages that build against parrot know how to pick it up?)

Just a little. We need to adjust the install_config.fpmc so that the 
linker option points to the installed specs file (and of course install 
the file). That way, the installed pbc_to_exe should pick it up, which 
should work for languages. People embedding parrot should probably use 
the compile flags from parrot_config, so they will be getting it 
aswell. The only "mess" I can see is conditionally installing another file.

When I was building parrot to verify the fix actually works for parrot 
aswell, I found one small remaining problem. When using g++ as the 
linker, the values-xpg4 does not seem to have the expected effect. I've 
verified with -v that it is actually used, still atan2 is giving the 
wrong result. Can you verify that, and if so, do you have an idea 
what's causing it?

RG.

PS: You can see the successful build at
http://smolder.plusthree.com/app/public_projects/report_details/19425