Package Details: gmt 5.4.5-2

Git Clone URL: https://aur.archlinux.org/gmt.git (read-only)
Package Base: gmt
Description: Generic Mapping Tools: Collection of tools for manipulating geographic and Cartesian data sets, and generating EPS maps.
Upstream URL: http://gmt.soest.hawaii.edu/
Licenses: LGPL
Conflicts: gmt4
Submitter: None
Maintainer: graziano
Last Packager: graziano
Votes: 20
Popularity: 0.825574
First Submitted: 2007-11-16 20:01
Last Updated: 2019-05-14 17:46

Latest Comments

1 2 3 Next › Last »

holishing commented on 2019-05-19 08:16

sometimes I ran into the issue @OvelixMax reported, but I still cannot reproduce this, I guess that if it is related to python-sphinx's version. (related problem: https://github.com/GenericMappingTools/pygmt/commit/997b88c855c12ffacd2c4b911f3fa83244ce8d7b )

OvelixMax commented on 2019-05-19 07:46

There was an error compiling this version. This is the final part (some text are in spanish due to my locale):

[ 93%] Building C object src/CMakeFiles/supplib.dir/x2sys/x2sys_merge.c.o

[ 96%] Linking C shared module plugins/supplements.so

[100%] Built target supplib

==> Entrando en entorno fakeroot...

==> Iniciando package()...

make: *** No hay ninguna regla para construir el objetivo 'docs_man'. Alto.

==> ERROR: Se produjo un fallo en package().

Cancelando...

Error making: gmt

holishing commented on 2019-05-09 21:20

Maybe License Information for this repository should be checked. https://github.com/GenericMappingTools/gmt/blob/master/LICENSE.TXT

(License of v5.x [or after][LGPL,GPL] is different from v4.x[GPL])

graziano commented on 2016-03-02 14:20

Thanks @richli, integrated patch. Reported upstream.

richli commented on 2016-03-02 01:00

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.

richli commented on 2016-02-29 23:28

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

Strawpants commented on 2014-02-13 21:14

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

graziano commented on 2013-11-14 07:40

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...

bidulock commented on 2013-11-14 01:20

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.

dumbojumbo commented on 2013-11-14 00:25

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.