GMT6 run-time error on Cygwin

Q&A
1

GMT 6.1.1 compiled and was built without any difficulties.

However when I try to run a program I get the following error message:

$ gmt
gmt [ERROR]: Failure while loading core GMT shared library: No such file or directory

This message is generated more or less first thing when the program starts. It would be good to know what it is not finding.
gmt-config also generates the same error message (4 times) before printing the usage message.

The PATH has been set using gmtswitch and points to the correct bin folder:

$ echo $PATH
.:/home/cff/this_gmt/bin:/home/cff/SeisUnix/bin:/usr/local/bin:/usr/bin: etc.

Any help or hints would be greatly appreciated.

Thanks
Carl Fredrik

2

You can try to change line 1017 of gmt_api.c to read

GMT_Report (API, GMT_MSG_ERROR, "Failure while loading core GMT shared library (%s): %s\n", API->lib[0].path, dlerror());

and rebuild.

My guess is that the shared lib (libgmt.so) is in a directory not seek by LD_LIBRARY_PATH. … or something else because Cygwin is tricky and we abandoned testing it long time ago.

3

Thanks,
The message now states it cannot find a libgmt.dll file.

I find libgmt-6.dll, libgmt.a and libgmt.dll.a files, but no libgmt.dll file in the gmt-6.1.1 and Cygwin folders.

Carl Fredrik

4

Hmm, the one of interest is libgmt-6.dll but GMT it’s looking for libgmt.dll (the non-versioned name). Try to make a symlink to see if tricks Cygwin.

As I said Cygwin …

5

Thanks Joaquim,
The symlink did trick Cygwin.

Carl Fredrik

6

Some more info:
The symlink worked, but only from the present working directory.
Otherwise the following error is produced (no path in file name):

gmt [ERROR]: Failure while loading core GMT shared library (libgmt.dll): No such file or directory.

Should I set a variable called GMT_CORE_LIB_NAME before building?

Carl Fredrik

7

Maybe set LIBRARY_PATH to include the full path to that ib.

8

Or simply use the Windows binaries.

9

I have been wondering about the Windows binaries. I have written several programs that use the GMT C API (under Cygwin) that access the same files through the network as our Linux server. Is the API included in the binaries and what about compilers? I have also been assuming that the Windows binaries use the Windows End-of-Line convention. I have therefore not ventured down that path.

I also tried Bash for Windows a few years back, but at the time I could not access the network drives through that. I have not tried since.

Cygwin has had its hiccups, but has, on the whole, worked well. The Linux server does not yet have GMT 6.

Carl Fredrik

10

Hmm, the EOL thing would probably not be an issue because GMT should be insensitive to that, but writing programs to access the GMT API that will pose the compilers problem. I don’t think gcc in Cygwin will be able to link against the lib created with Visual Studio. MinGW’s gcc perhaps but Cygwin’s, almost sure it wont. But Cygwin can have the MinGW’s compatibility so … I don’t know.

The main issue with Cygwin build is probably the WIN32 vs _WIN32 macro duality. Their scope is very confuse and we tend to use them freely. It is not impossible that sometimes we are letting a Windows behavior slipping into Cygwin’s Posix environment. It’s not impossible that the trouble you found with the dll comes from that reason, though I’m not seeing how.

11

I re-installed the project after editing the build/src/config.h file line 62 to:
#define GMT_CORE_LIB_NAME “libgmt-6.dll”
wirh:
cmake --build . --target install

after that all worked fine.

For the record the old line was:
#define GMT_CORE_LIB_NAME “libgmt.dll”

Carl Fredrik

12

OK, but that’s no solution because GMT_CORE_LIB_NAME is defined in config.h.in and gets set by cmake.

#define GMT_CORE_LIB_NAME "@GMT_CORE_LIB_NAME@"
13

Note, you have to make de symlink in the same dir where libgmt-6.dll lives, not in current dir.

14

I realize it is a rather dirty tweek. The motivation camfrom noticing that during installation (before tweeking) The following messages were produced:

[100%] Linking C shared module plugins/supplements.so
[100%] Built target supplements
Scanning dependencies of target gmt
[100%] Building C object src/CMakeFiles/gmt.dir/gmt.c.o
[100%] Linking C executable gmt.exe
[100%] Built target gmt
Install the project…
– Install configuration: “Release”
– Installing: /GMT6/gmt-6.1.1/lib/libgmt.dll.a
– Installing: /GMT6/gmt-6.1.1/bin/libgmt-6.dll
– Installing: /GMT6/gmt-6.1.1/lib/libpostscriptlight.dll.a
– Installing: /GMT6/gmt-6.1.1/bin/libpostscriptlight-6.dll
– Installing: /GMT6/gmt-6.1.1/bin/gmt.exe

However the config.h file referenced libgmt.dll on line 62.

Further motivation from:
The GMT5 build/src/config.h file contains libgmt-5.dll at the equivalent place, so I tested the tweek

Carl Fredrik

15

OK, I think that is what I did initially, but I am not sure. It seemed to work until I changed directory.
I suppose I can re-install with the original “libgmt.dll” and test to make sure.

Carl Fredrik

16

Yep, the problem originates in CMakeList.txt

# Get name of GMT core library
get_target_property (_name gmtlib RUNTIME_OUTPUT_NAME)
get_target_property (_prefix gmtlib PREFIX)
set (GMT_CORE_LIB_NAME ${_prefix}${_name}${_lib_suffix})
17

I reinstalled and can confirm that the symlink only works in the when the working directory the folder where the symlink is stored.

Carl Fredrik

18

You can try also to make a true copy or rename the libgmt-6.dll to libgmt.dll. This wouldn’t work in true Windows because the dlls have their names embedded but perhaps it does on Cygwin