Closed richardsc closed 8 years ago
Interesting. The simple way to fix that is to copy the M_PI definition from another compiler. (They seem to have changed gcc-6) I'm off to a proposal defence but can do this in 3 minutes this aft.
PS. the gcc-6 webpage is a bit scary (quote: "huge number of improvements in GCC 6"). I don't like the sounds of "huge".
I think I've fixed this in commit 80a92f1a3655216950aed8fa48ce8f7b976d10ef
I reported this here, but I wonder if this should be reported upstream in the GSW-C repo? That way when we do (eventually) update to the more recent C sources we won't have to deal with it again ...
I don't think this applies to GSW-C; it is just in code that I transliterated into C. In GSW-C, pi is defined as below. But I used M_PI
because I prefer to use values from the C include files. As to why this is no longer present, I have no idea. But it doesn't matter hugely, I think, because the code fix that I put in will use the system-provided M_PI
if there is one, falling back to a numerical definition otherwise. (As an aside, the definition I've used has 32 digits, compared to the 18 digits used in GSW-C. I suppose I could switch mine, but this passes the R build-check and so I don't see the point in degrading the number unless we had a check-value failure.)
$ grep -ni 3.141592 *
gsw_internal_const.h:14: pi = 3.141592653589793, \
From https://www.r-project.org/nosvn/R.check/r-devel-linux-x86_64-debian-gcc/gsw-00check.html
Details: