Skip to content

A potential bug in guessing GMT's share directory #3353

@seisman

Description

@seisman

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

/* SHAREDIR still not found, make a smart guess based on runpath: */
if (gmt_guess_sharedir (path, GMT->init.runtime_bindir))
GMT->session.SHAREDIR = gmt_strdup_noquote (path);
else {
/* Still not found */
GMT_Report (GMT->parent, GMT_MSG_ERROR, "Could not locate share directory for GMT.\n");
GMT_exit (GMT, GMT_RUNTIME_ERROR); return GMT_RUNTIME_ERROR;
}
.

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 variable runtime_libdir ends with bin, e.g., D:/bld/gmt_1589870953348/_test_env/Library/bin. As the default value of GMT_LIBDIR_RELATIVE is lib, sharedir_from_runtime_libdir can't determine the sharedir by replacing GMT_LIBDIR_RELATIVE with GMT_SHARE_DIR_RELATIVE (e.g., conda uses share/gmt). Thus, the function sharedir_from_runtime_libdir returns NULL.

Then GMT tries to guess sharedir from runtime_bindir. When running GMT command line, the variable runtime_bindir has a value D:/bld/gmt_1589870953348/_test_env/Library/bin, then it can replace bin with share/gmt. However, when PyGMT loads the GMT library, the variable's value is D:/bld/gmt_1589870953348/_test_env.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions