Package Details: gmt 5.2.1-3

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: GPL
Conflicts: gmt4
Submitter: None
Maintainer: graziano
Last Packager: graziano
Votes: 15
Popularity: 0.102208
First Submitted: 2007-11-16 20:01
Last Updated: 2016-03-02 14:20

Dependencies (8)

Required by (1)

Sources (2)

Latest Comments

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.

dumbojumbo commented on 2013-11-13 23:55

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.

graziano commented on 2013-11-13 18:30

The gmt4 package has been added to aur for this.

dumbojumbo commented on 2013-11-13 18:29

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?

bidulock commented on 2013-03-25 00:48

PKGBUILD needs to be split into build() and package().

helmuthdu commented on 2013-01-08 20:24

Here is an updates PKGBUILD with no relative patch on ./configure...
http://pastebin.com/4UTTkY3Y

This package need to downgread the hdf5 to version 1.8.8 (only way i could make it work).

cucullus commented on 2012-02-06 14:12

Please, do not use relative path in configure!! The only trick you need is to specify 'DESTDIR=${pkgdir}' in 'make install-all'.

graziano commented on 2012-02-06 09:13

Added octave dependency and build of mexfiles.

cucullus commented on 2011-12-09 16:55

Current pkgbuild is completely unusable! Here is working one: http://pastebin.com/yq6WvaJx

graziano commented on 2011-03-25 16:01

got. Thanks cucullus.

cucullus commented on 2011-03-25 15:44

ok, I managed to compile.
Please consider to add MAKEFLAGS="-j1", otherwise build fails. And change mv to cp, because mv prevents yaourt's "restart build" function to work.

cucullus commented on 2011-03-24 11:57

I got: *** No rule to make target `../libgmtps.a', needed by `psmeca'. Stop.

fluxness commented on 2010-11-18 10:43

Version 4.5.3 is now 4.5.5 !

Updated PKGBUILD: http://aur.pastebin.com/iiBu6yQ0

After exporting GMTHOME and GMT_SHAREDIR:

"export GMTHOME=/usr/share/gmt"
"export GMT_SHAREDIR=/usr/share/gmt"

it should work.

ARCHologist commented on 2010-09-19 14:23

I updated, set the variable in my .bashrc and it works fine now. Thanks a lot.

beej commented on 2010-08-30 21:35

It seems there might be something racy in the Makefiles. I was doing a two-process build--I had the line MAKEFLAGS="-j2" in my /etc/makepkg.conf; when I commented that out, it built fine.

beej commented on 2010-08-12 01:15

I'm getting a build error on this, but it might be upstream...

Relevant search terms: No rule to make target ../libgmtps.a, needed by psmeca

Here's more context: http://aur.pastebin.com/Y9StGcDh

Anonymous comment on 2010-08-11 00:40

I think you need to set the GMT_SHAREDIR variable to /usr/share/gmt either in $HOME/.bashrc, /etc/profile or any other appropriate place I'm not aware of.

ARCHologist commented on 2010-04-16 21:43

I am getting an error while trying to generate a map:
GMT Fatal Error: /tmp/yaourt-tmp-USERNAME/aur-gmt/gmt/pkg/usr/share/gmt/PS_font_info.d: No such file or directory

In /usr/bin/GMT $datarootdir is defined as /tmp/yaourt-tmp-USERNAME/aur-gmt/gmt/pkg/usr/share/gmt/. Shouldn´t that be just /usr/share/gmt where the program is installed?

ARCHologist commented on 2010-04-16 21:26

I am getting an error while trying to generate a map:
GMT Fatal Error: /tmp/yaourt-tmp-USERNAME/aur-gmt/gmt/pkg/usr/share/gmt/PS_font_info.d: No such file or directory

In /usr/bin/GMT $datarootdir is defined as /tmp/yaourt-tmp-USERNAME/aur-gmt/gmt/pkg/usr/share/gmt/. Shouldn´t that be just /usr/share/gmt where the program is installed?