Fix issues for running on Windows

[leouieda]

Description of proposed changes

Trying to fix the issues for running on Windows now that we have CI.

Fixes #46

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If adding new functionality, add an example to docstrings or tutorials.

[seisman]

If both ctypes.CDLL and check_libgmt don't raise any errors, it means we find the library, then we should break out of the loop. Right?

Suggested change

	check_libgmt(libgmt)
	check_libgmt(libgmt)
	break

[leouieda]

Of course! Thanks, Dongdong. I stopped coding yesterday because I couldn't even see this basic error anymore :)

[weiji14]

I just realized that this change is part of what's been causing our Windows builds to fail... Since we have a list of dll files to check, if one of the dll fails, the variable error turns True and stays True even if a later dll works. Our Linux and MacOS tests work because there's only one item in the list.

[leouieda]

I managed to track down the failures to GMT API session creation causing a crash. It might be something that Windows is a bit more sensitive to. Need to investigate.

[seisman]

Just provide more information:

I tried pygmt with the latest master branch of GMT. It works well. Running pygmt.test() results in some failed tests, same as what I saw several months ago in #285.

I also tried GMT 6.0.0rc1 provided by conda-forge. GMT itself works well on Windows, but import pygmt crashes.

[leouieda]

Yeah, I'm still scratching my head over this one. I wondered if it's a compiler flag on the conda recipe that is messing things up.

[leouieda]

I just noticed that the conda-forge build log has Build GMT for developers : yes in the cmake log. @seisman do you know if this means we're making debug build by mistake?

[seisman]

No. It only means installing the header files (*.h) for developers.

[leouieda]

Yeah I figured we wouldn't be this lucky. Thanks

[leouieda]

Oh good. Now with rc2 the Linux build is failing.

[weiji14]

It's crashing on this line:

pygmt/pygmt/clib/session.py

Line 348 in da2cfec

session = c_create_session(name.encode(), padding, session_type, print_func)

[seisman]

Yes, but as I said in previous comments, pygmt works with self-built GMT on Windows, but fails with the GMT provided by conda-forge. So it's really difficult to track down the crash.

[leouieda]

@weiji14 😢 yeah, this has bugged me quite a bit. I don't think it's a ctypes issue. I suspect it might be something to do with our conda-forge build. I'm going to work hard on this and some other major issues this week. Hopefully we can get the major blocking points for 0.1 done before AGU 🤞

[michaelgrund]

Hey guys,
after some time, I finally got pygmt properly working on my Windows 10 notebook using Anaconda. However, for this purpose I made use of the Linux subsystem available from the latest Win10 versions. I followed the instructions given here https://gist.github.com/kauffmanes/5e74916617f9993bc3479f401dfec7da to install Anaconda first. Afterwards it was quite easy to install pygmt as outlined in the installing section using the bash available from the Linux subsystem. Putting GMT_LIBRARY_PATH=$HOME/anaconda3/envs/pygmt/lib into .bashrc also works quite well without any errors and warnings. Finally, I successfully tested some of my pygmt jupyter notebooks developed on my "real" Linux machine. I know this is no perfect solution, but probably it may serve as workaround for some of the windows users.

[leouieda]

Hi @michaelgrund thanks for sharing! Yeah, we might just have to stick with that for now. It's not the ideal solution since it wouldn't integrate with a user's existing setup.

[seisman]

The issue was fixed in #434.