-
Notifications
You must be signed in to change notification settings - Fork 361
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A potential bug in guessing GMT's share directory #3353
Comments
Unless I misunderstand the above, seems like under Windows the GMT_LIBDIR_RELATIVE should be bin? Also, do you understand why D:/bld/gmt_1589870953348/_test_env is returned? What is returning that? Do you mean runtime_bindir returns that path? Is that the path to the gmtPy script? |
YES, I think so.
I added a print statement before line 362. The value of the variable Lines 358 to 367 in a1e72e6
The value of the variable Lines 105 to 108 in a1e72e6
|
When @ldldr wrote that, he was not anticipating any other program that gmt.c calling it (I think). So here you get the path to the Python interpreter instead, which may or may not have a directory that is useful for this fishing expedition. Perhaps a better approach is to recognized that when API->external is true (and we are calling GMT from MEX, Julia, Python) taht we instead do a quick system call to get the output of
as long as gmt is installed in the path (which it surely will be), you get the right dir. I will hack up a branch for testing. |
In
to
works for pygmt. Seems a good solution if |
Great, should we leave my external code as a backup in case the fishing fails? |
On Windows, the gmt.dll is located in the `bin` directory, instead of the usual `lib` directory. Thus, for windows, we need to set `GMT_LIBDIR_RELATIVE` to `bin`. Closes #3353.
Perhaps not necessary now. I want to avoid calling external command when loading libraries. |
OK, will count on you to remember this scheme should it become necessary in the future. I will delete the branch. |
On Windows, the gmt.dll is located in the `bin` directory, instead of the usual `lib` directory. Thus, for windows, we need to set `GMT_LIBDIR_RELATIVE` to `bin`. Closes #3353.
The variable GMT_SHAREDIR was needed due to a GMT bug. See GenericMappingTools/gmt#3353 for the bug report, and GenericMappingTools/gmt#3361 for the fix. The conda GMT package was rebuilt in conda-forge/gmt-feedstock#94, in which the patch was applied to GMT 6.0.0. Now PyGMT should work well with no need to add the variable GMT_SHAREDIR.
The variable GMT_SHAREDIR was needed due to a GMT bug. See GenericMappingTools/gmt#3353 for the bug report, and GenericMappingTools/gmt#3361 for the fix. The conda GMT package was rebuilt in conda-forge/gmt-feedstock#94, in which the patch was applied to GMT 6.0.0. Now PyGMT should work well with no need to add the variable GMT_SHAREDIR.
PyGMT crashes with the conda GMT package on Windows. After some debugging, it turns out GMT cannot determine its sharedir for the conda GMT package.
Unlike GMT's official installers, the conda GMT package doesn't define environmental variables GMT6_SHAREDIR, GMT5_SHAREDIR or GMT_SHAREDIR. Thus, GMT has to guess the share directory by calling
gmt_guess_sharedir
:gmt/src/gmt_init.c
Lines 3019 to 3026 in 28efd94
The function
sharedir_from_runtime_libdir
tries to guess sharedir from runtime_libdir. For Windows, because the gmt.dll library is in the bin directory, the variableruntime_libdir
ends withbin
, e.g.,D:/bld/gmt_1589870953348/_test_env/Library/bin
. As the default value ofGMT_LIBDIR_RELATIVE
islib
,sharedir_from_runtime_libdir
can't determine the sharedir by replacingGMT_LIBDIR_RELATIVE
withGMT_SHARE_DIR_RELATIVE
(e.g., conda usesshare/gmt
). Thus, the functionsharedir_from_runtime_libdir
returns NULL.Then GMT tries to guess sharedir from
runtime_bindir
. When running GMT command line, the variableruntime_bindir
has a valueD:/bld/gmt_1589870953348/_test_env/Library/bin
, then it can replacebin
withshare/gmt
. However, when PyGMT loads the GMT library, the variable's value isD:/bld/gmt_1589870953348/_test_env
.The text was updated successfully, but these errors were encountered: