Arch Linux User Repository

Thanks @richli, integrated patch. Reported upstream.

I don't know exactly what caused the problem (because it worked for me when I last compiled it on 2016-01-14), but a simple cast silences the error. This should probably be reported upstream.

Meanwhile, I have the updated package here:

https://gist.github.com/richli/76d55a4557a7c6ea9d21

The addition is in the "float_cast.patch" file. I also made some minor changes to the PKGBUILD.

I can no longer seem to compile:

./gmt/src/gmt-5.2.1/src/xyz2grd.c: In function ‘GMT_xyz2grd’:
./gmt/src/gmt-5.2.1/src/xyz2grd.c:752:4: error: non-floating-point argument in call to function ‘__builtin_isnan’
(GMT_is_dnan (GMT->common.d.active[GMT_IN])) ? sprintf (e_value, "NaN") : sprintf (e_value, GMT->current.setting.format_float_out, GMT->common.d.nan_proxy[GMT_I
^
src/CMakeFiles/gmtlib.dir/build.make:2443: recipe for target 'src/CMakeFiles/gmtlib.dir/xyz2grd.c.o' failed
make[2]: *** [src/CMakeFiles/gmtlib.dir/xyz2grd.c.o] Error 1
CMakeFiles/Makefile2:278: recipe for target 'src/CMakeFiles/gmtlib.dir/all' failed
make[1]: *** [src/CMakeFiles/gmtlib.dir/all] Error 2
Makefile:149: recipe for target 'all' failed
make: *** [all] Error 2

Maybe as a suggestion: change ${startdir}/src to ${srcdir} in the PKGBUILD. Then it will use the BUILDDIR from /etc/makepkg.conf.

Moreover, upstream the University of Hawaii has flagged "GMT 4.5.11 - The latest stable GMT 4 version", so there won't be any more development on the 4.x branch...

python was a mess. FWIW, I think grziano's current approach is best: gmt4 for legacy, gmt rolling. That way gmt4 can be easily dropped at some point.

Perhaps I was not clear in conveying my point. I see that you have created gmt4, but infact you should have started gmt5 separately. There are subtle differences between GMT4 and GMT5 and the scripts that worked with GMT4 won't work with GMT5 anymore, as by default the system will call upon GMT5 functions after the current upgrade. The advantage with starting gmt5 separately is that the current upgrade will not hinder the GMT4 users. And if they want they could install GMT5 in /opt or /usr/local/gmt5. Moreover, GMT5 comes with a main wrapper function "gmt" which can be used with a suffix as in "gmt5" or something else, so there wouldn't be any confusion in using that compared to the situation now. The current set up might not be a problem at all if people start with GMT5, but for people who will upgrade this might be a pain in the neck. I think this situation is similar to the one between python2 and python3.

Perhaps I was not clear in conveying my point. I see that you have created gmt4, but infact you should have started gmt5 separately. There are subtle differences between GMT4 and GMT5 and the scripts that worked with GMT4 won't work with GMT5 anymore, as by default the system will call upon GMT5 functions after the current upgrade. The advantage with that is GMT5 comes with a main wrapper function "gmt" which can be used with a suffix as in "gmt5" or something else, so there wouldn't be any confusion in using that compared to the situation now. You also say that GMT4.5.11 is a conflict to GMT5.1.0, which only complicates things. This might not be a big problem if people start with GMT5, but for people who will upgrade this might be a pain in the neck. I think this situation is similar to the one between python2 and python3.

Hope this time around I made my point clear to you.

The gmt4 package has been added to aur for this.

I think the logical upgrade to GMT 4.5.9 should have been GMT 4.5.11 and not GMT 5.1.0. This renders the scripts made for GMT 4.5.9 unusable. And it would have been sensible to start a gmt5, and also in gmt5 there is an option to add prefix to the commands. Would this be something to reconsider?