[PROJ] PROJ 6.0.0RC3

[Greg Troxel]

Even Rouault <even.rouault at spatialys.com> writes:

> On mardi 26 février 2019 16:41:56 CET Even Rouault wrote:
>> Might be a problem that only occurs on NetBSD.
>> I'm downloading an installation DVD, and will try to setup a VM to see if I
>> can reproduce, but I'm a noob in NetBSD...
>
> Was a bit painful as expected, but I managed to reproduce the issue. Removing 
> #define _XOPEN_SOURCE 500 fixes the issue on netBSD 8, and it doesn't seem to 
> hurt on Linux as well. https://github.com/OSGeo/proj.4/pull/1293 in progress 
> to check this. I suspect this might have been useful when this was a .c file, 
> but no longer as a .cpp one.

As I understand things, somewhat fuzzily, once you turn on
_XOPEN_SOURCE, then definitions not specific by xopen are hidden.  So
one might also have to turn on some POSIX visibility function, or some
other one.  Without any, pretty much everything is visible.

> When running the test suite, I had a small tolerance issue in gie tests 
> addressed by relaxing it in the PR.

I wonder if this is about 64 vs 80 bit doubles or about libm functions.
I have run Kahan's paranoia which passes without issues.

But if you are comfortable with slightly increased tolerances, that's
fine.

> The C++ unit tests also fail on io.wkt_parsing_with_parenthesis. I've been 
> unable to determine the cause. Presumably the use of non-ASCII characters in 
> hexadecimal form. Not sure why this would be netBSD specific... But this is is 
> really a non-critical test.

(I see your followup.)

> Note: gmake and not make is required on netBSD, since we have apparently some 
> gnu'ism in particular to build proj.db or run the test suite

The pkgsrc entry is already coded to require GNU make, so I didn't even
try with the native BSD make.