Installation failure

[timholy]

I'm looking into your report of lots of zeros in the dll file. I'm trying to build GMT on a system that I can run rr on but running up against this in deps/build.log:

Warning: 'conda-forge' already in 'channels' list, moving to the top
Collecting package metadata (current_repodata.json): ...working... done
Solving environment: ...working... done

## Package Plan ##

  environment location: /home/tim/.julia/conda/3

  added / updated specs:
    - gmt


The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    ca-certificates-2022.12.7  |       ha878542_0         143 KB  conda-forge
    certifi-2022.12.7          |     pyhd8ed1ab_0         147 KB  conda-forge
    conda-22.11.1              |   py38h578d9bd_1         905 KB  conda-forge
    pluggy-1.0.0               |     pyhd8ed1ab_5          16 KB  conda-forge
    ruamel.yaml-0.17.21        |   py38h0a891b7_1         172 KB  conda-forge
    ruamel.yaml.clib-0.2.6     |   py38h5eee18b_1         143 KB
    toolz-0.12.0               |     pyhd8ed1ab_0          48 KB  conda-forge
    ------------------------------------------------------------
                                           Total:         1.5 MB

The following NEW packages will be INSTALLED:

  pluggy             conda-forge/noarch::pluggy-1.0.0-pyhd8ed1ab_5
  ruamel.yaml        conda-forge/linux-64::ruamel.yaml-0.17.21-py38h0a891b7_1
  ruamel.yaml.clib   pkgs/main/linux-64::ruamel.yaml.clib-0.2.6-py38h5eee18b_1
  toolz              conda-forge/noarch::toolz-0.12.0-pyhd8ed1ab_0

The following packages will be UPDATED:

  ca-certificates                      2021.10.8-ha878542_0 --> 2022.12.7-ha878542_0
  certifi            conda-forge/linux-64::certifi-2021.10~ --> conda-forge/noarch::certifi-2022.12.7-pyhd8ed1ab_0
  conda                               4.11.0-py38h578d9bd_0 --> 22.11.1-py38h578d9bd_1



Downloading and Extracting Packages
ruamel.yaml-0.17.21  | 172 KB    | ########## | 100%
ruamel.yaml.clib-0.2 | 143 KB    | ########## | 100%
certifi-2022.12.7    | 147 KB    | ########## | 100%
conda-22.11.1        | 905 KB    | ########## | 100%
toolz-0.12.0         | 48 KB     | ########## | 100%
pluggy-1.0.0         | 16 KB     | ########## | 100%
ca-certificates-2022 | 143 KB    | ########## | 100%
Preparing transaction: ...working... done
Verifying transaction: ...working... done
Executing transaction: ...working... done
/home/tim/.julia/conda/3/bin/gmt: symbol lookup error: /home/tim/.julia/conda/3/bin/../lib/./libgdal.so.30: undefined symbol: _ZN21GfxICCBasedColorSpace15buildTransformsEP8GfxState
[ Info: Running `conda config --add channels conda-forge --file /home/tim/.julia/conda/3/condarc-julia.yml --force` in root environment
[ Info: Running `conda install -y gmt` in root environment
Base.IOError("could not spawn `gmt --version`: no such file or directory (ENOENT)", -2)
ProcessFailedException(Base.Process[Process(`/home/tim/.julia/conda/3/bin/gmt --show-library`, ProcessExited(127))])

[joa-quim]

You mean, building GMT from source?

We have this page to help with that but I'm sorry that it looks so complicated, even for experimented people
https://github.com/GenericMappingTools/gmt/blob/master/BUILDING.md#building-gmt-source-codes

I always copy my ConfigUser.cmake from computer to computer so don't feel that pain. However, it's pretty standard unix procedure. (1) install the the dependencies. (2) config cmake. (3) build.
This should do it.

sudo apt-get install -y --no-install-recommends --no-install-suggests cmake ninja-build libcurl4-gnutls-dev libnetcdf-dev ghostscript curl git libgdal-dev libfftw3-dev libpcre3-dev liblapack-dev libglib2.0-dev 

git clone --depth 50 https://github.com/GenericMappingTools/gmt

cd gmt
mkdir build
cd build
cmake -G 'Ninja' cmake .. G Ninja -DCMAKE_INSTALL_PREFIX="/opt/gmt"  ..
ninja install

But note that I also found those zero blocks in the Makie dll.

Once you have GMT installed system-wide installing GMT.jl just finds it and ignores the conda install fallback.

[timholy]

No, I'm just following the installation instructions: https://github.com/GenericMappingTools/GMT.jl#install. I don't need a debug build of GMT itself.

[joa-quim]

Sorry, hadn't noticed the

/home/tim/.julia/conda/3/bin/gmt: symbol lookup error: /home/tim/.julia/conda/3/bin/../lib/./libgdal.so.30: undefined symbol: _ZN21GfxICCBasedColorSpace15buildTransformsEP8GfxState

It's the first time I see this one. Will have to ask to my colleagues who more or less take care of building GMT with Conda. What is your Linux?

[timholy]

One is Ubuntu 20.04 and the other Ubuntu 18.04. Neither works, but I think that error message is from the 20.04 one.

[timholy]

If you want to consider system-independent binaries, I understand BinaryBuilder does all this very nicely. But I have no personal experience.

[joa-quim]

I'm really puzzled with that. The GMT docs are built with Franklin which uses GH actions that I have tried also in Linux. It's true that I have several mysterious errors when the run is done in Linux but at least it installs fine (using Conda for GMT) and builds parts of the docs.

Regarding the BinaryBuilder, I have no experience myself but others have tried and there is a problem building the Windows binaries. Another problem is that the GDAL build is quite limited and does not include netCDF/HDF which is a no-no for GMT.jl. See same comments in #1049 (comment)

[joa-quim]

Could it be that you already have another Conda package that installs GDAL and this conflicts with GMT?

[timholy]

In a fresh JULIA_DEPOT_PATH it seems to work, great!

In the meantime I think we've solved the mystery of the runs of zeros in the dlls. There doesn't appear to be any bug/underlying problem, but that's a data section we can compress. It's not going to be a big change in the file size, but every bit helps. Thanks for calling our attention to it.

[timholy]

another Conda package that installs GDAL and this conflicts with GMT?

Might a previous version of GMT be the source of the conflict? I don't know of anything that would otherwise install GDAL (none of my science uses it, and my work on julia master has solely been about getting Julia working; I seem to remember looking at something for you on nightly a few months back).

[joa-quim]

Yes, I remember too that some half year ago you tried to install GMT and something didn't go well but I never knew what.
Happy that my sneaky nose helped in something.

[joa-quim]

GMT is now using a GMT_jll artifact on master. But still lots of issues with new libCURL on nightly. Thousands of artifacts are broken on nightly because of it.

[joa-quim]

GMT_jll is now on a release version (1.0) so install problems should have gone.