Question on using the GMT wrapper

New to Julia
1

Hi all,

I have a macOS, running Julia on Juno. I am trying to install the GMT wrapper into Julia, and it seems to work at a glance. However, when I run GMT, I get the following error:

ERROR: error compiling finish_PS_module: error compiling gmt: could not load library “libgmt”
dlopen(libgmt.dylib, 1): image not found

I have installed GMT6 using the application, and GMT6 runs fine on Terminal. Might I know what the issue here is though? I tried to define libgmt.dylib, and got another error in that I was unable to define the variable.

Cheers!

2

Have you tried going into the package manager shell and doing ] build GMT? Sometimes you need to do that for the package to connect with those external libraries. I’ve run GMT from Julia in the past, but haven’t done in a while.

3

Quoting from: GitHub - GenericMappingTools/GMT.jl at 94f8b13f7beabcc4f198166f45bb3bcd7eedbba8 (emphasise not mine)

]build GMT would do nothing, there is no deps/build.jl file.

4

Ok, good to know. Then it’s something related to paths, probably?

5

I think it’s something to do with the libgmt paths, but I’m not sure how to do in and change it.

6

Hi,
Unfortunately we have this mystery on OSX that is tackled in this issue. Basically if user installs GMT using, for instances, homebrew then all goes well. However, if user uses our GMT bundle, which works perfectly well on bash shell, then incomprehensible dependency conflicts come up. That is what @natgeo-wong is facing. I want also to emphasize that this dependency conflict with the bundle does not restrict to the Julia wrapper. We also face a similar situation with the Matlab and PyGMT interfaces. And that is all in OSX. Other OS do not suffer from it.

Any help from people with knowledge of the OSX linking mechanism that can help us on this will be most well come.

7

Thank you very much! I will download the GMT from homebrew instead!

8

Hi! I installed using Brew, however I’m getting the following error:

ERROR: ccall: could not find function gmt_manage_workflow in library libgmt
Stacktrace:
[1] gmt_manage_workflow at /Users/natgeo-wong/.julia/packages/GMT/Ba3R6/src/libgmt.jl:389 [inlined]
[2] gmt(::String) at /Users/natgeo-wong/.julia/packages/GMT/Ba3R6/src/gmt_main.jl:138
[3] finish_PS_module(::Dict{Symbol,Any}, ::String, ::String, ::String, ::String, ::String, ::Bool, ::Bool, ::Bool) at /Users/natgeo-wong/.julia/packages/GMT/Ba3R6/src/common_options.jl:2189
[4] #coast#193(::Nothing, ::Bool, ::Base.Iterators.Pairs{Symbol,Any,NTuple{8,Symbol},NamedTuple{(:region, :proj, :frame, :area, :land, :water, :figsize, :show),Tuple{Symbol,Symbol,Symbol,Int64,Symbol,Symbol,Int64,Bool}}}, ::typeof(coast), ::String) at /Users/natgeo-wong/.julia/packages/GMT/Ba3R6/src/pscoast.jl:147
[5] (::getfield(GMT, Symbol(“#kw##coast”)))(::NamedTuple{(:region, :proj, :frame, :area, :land, :water, :figsize, :show),Tuple{Symbol,Symbol,Symbol,Int64,Symbol,Symbol,Int64,Bool}}, ::typeof(coast)) at ./none:0
[6] top-level scope at none:0

I am currently using GMT5 because the brew version does not support GMT6 installation. Is this an issue due to this version discrepancy?

9

Yes, although I intend to make the wrapper work with GMT5 as well I’ve not tested for a while (the development is all done with GMT6). And yes, since GMT6.0 is not yet officially out (only the RC4) homebrew does not have a formula yet but you can use this one (shown in the issue that pointed above)

brew install https://raw.githubusercontent.com/claudiodsf/homebrew-core/GMT6.0.0/Formula/gmt.rb
10

Thank you, I will attempt to use this later!

11

And I’ll try to make work again with GMT5

12

But it does work with GMT5. The error you got came from this line, which is only executed if GMTver == 6 and that variable is set in the GMT.jl at this line by inquiring the system what GMT version you have installed. I don’t see how it can get a value 6.0 if you only ever had GMT5.

What I just found and it’s not so nice is that after GMT.jl gets pre-compiled then even if you update the GMT version, the info about the version in the wrapper is not updated unless one forces recompiling GMT.jl

13

I think maybe those constants should be set in __init__() so they don’t get precompiled (docs).

14

Thanks, you are probably right but I then fall into other problems because I need to know the value of the `GMTver`` at compile time in other included files. The issue is that several C structs in GMT have different contents on the two versions (5 or 6) and I need to know which one to ccal and apparently that is decided at compile time and not at runtime.

15

Ah ok. Maybe it can be done at build time (build/build.jl writes a file deps/constants.jl that has the values hardcoded and is included by the package). That way the user can call Pkg.build(“GMT”) to reset the constants.

I’m not really sure if that’s actually better than the current system though.

16

Hmmmmm alright, I’ll try that again! Thanks for the head’s up, yeah because I installed GMTv6 first before moving over to GMTv5 when it didn’t work.

17

But if you have GMT6, by all means use it instead of GMT5, The issue is that you need to force a GMT.jl precompile when you change your GMT version. A dirty way is to just change something irrelevant in GMT.jl and next time you do using GMT it will be re-precompiled.

18

I made a commit to master that warns users when they are caught in that situation of GMT.jl being out of phase with the installed GMT version.

19

Mmmmmm I need to reinstall GMT6 using homebrew because it doesn’t work when I download the GMT6.app, which was the initial problem.

Thank you all so much for your time and your help!