# Conda GMT build is unusable in Julia-Windows
**URL:** https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677
**Category:** Q&A
**Created:** [May 12, 2021, 2:32pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677 "2021-05-12T14:32:30Z")
**Posts on this page:** 13
**Page:** 1
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 12, 2021, 2:32pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/1 "2021-05-12T14:32:30Z")
I know this is not the right place to report Conda issues but I’m not sure where to do it and perhaps our Py guys can redirect this to its due place.
The issue is that somehow the Conda build is screwing somewhere and in a mysterious way. Although the binaries work, they cannot be used from Julia. See, working from the Conda bin dir
```auto
julia> pwd()
"C:\\programs\\Miniconda3\\Library\\bin"
```
now, try a GMT, GDAL and PROJ4 dlls. Only the latter works
```auto
julia> ccall((:GMT_Create_Session, "gmt"), Ptr{Cvoid}, (Ptr{UInt8}, UInt32, UInt32, Ptr{Cvoid}), "GMT", 2, 0, C_NULL)
ERROR: could not load library "gmt"
The specified procedure could not be found.
julia> ccall((:GDALVersionInfo, "gdal302"), Cstring, (Cstring,), "--version")
ERROR: could not load library "gdal302"
The specified procedure could not be found.
julia> ccall((:proj_create, "proj_8_0"), Ptr{Cvoid}, (Ptr{Cvoid}, Cstring), C_NULL, "+proj=longlat")
Ptr{Nothing} @0x000000006faaec40
```
For checking let’s repeat the above but using our own GMT build
```auto
julia> ccall((:GMT_Create_Session, "gmt_w64"), Ptr{Cvoid}, (Ptr{UInt8}, UInt32, UInt32, Ptr{Cvoid}), "GMT", 2, 0, C_NULL)
Ptr{Nothing} @0x000000007e462380
julia> ccall((:GDALVersionInfo, "gdal_w64"), Cstring, (Cstring,), "--version")
Cstring(0x000000007e3ea0b0)
julia> ccall((:proj_create, "proj_w64"), Ptr{Cvoid}, (Ptr{Cvoid}, Cstring), C_NULL, "+proj=longlat")
Ptr{Nothing} @0x000000007e49d4c0
```
All three commands worked well.
I have now quite some experience tracking the very misleading error message _The specified procedure could not be found_ but after quite some time investigating with the _DependencyWalker_ I could not find the failing reason, but the point is: those binaries are useless for Julia (and very likely all other FFI interfaces) usage on Windows.
---
### Author:  [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)
#### Post date: [May 13, 2021, 12:11am UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/2 "2021-05-13T00:11:29Z")
Strange that both GMT and GDAL isn’t working. The conda build recipe for GMT and GDAL on Windows is at [https://github.com/conda-forge/gmt-feedstock/blob/master/recipe/bld.bat](https://github.com/conda-forge/gmt-feedstock/blob/master/recipe/bld.bat) and [https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/set\_bld\_opts.bat](https://github.com/conda-forge/gdal-feedstock/blob/master/recipe/set_bld_opts.bat) respectively, not sure if you can spot anything that is wrong there. My next guess is that it is something to do with the %PATH% environment variable, could you print the %PATH% for the conda install and GMT build install perhaps?
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 13, 2021, 12:33am UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/3 "2021-05-13T00:33:52Z")
Hi Weiji
No the problem should not be the `PATH`. See that I run those commands from within the directory where conda puts the binaries+dlls
```auto
"C:\\programs\\Miniconda3\\Library\\bin"
```
I don’t see anything wrong in the building recipes and it’s certainly strange that the executables run but calling the dlls fail. The build is done by VCPKG? I’ve seen it doing crazy things in building GDAL (tons of `Boost` shits)
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 13, 2021, 12:59am UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/4 "2021-05-13T00:59:10Z")
BTW, another thing. Where does conda stores the GMT binaries on Linux? I’m trying to mimic what I see on Windows but the executable isn’t apparently there (never mind the `.julia/conda/3` part, that’s the Conda/Julia location)
```auto
ERROR: LoadError: IOError: could not spawn `/home/runner/.julia/conda/3/Library/bin/gmt --show-library`: no such file or directory (ENOENT)
```
---
### Author:  [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)
#### Post date: [May 13, 2021, 1:12am UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/5 "2021-05-13T01:12:22Z")
Just double checking that you ran `conda activate myenvname` (see [Managing environments — conda 24.1.3.dev32 documentation](https://conda.io/projects/conda/en/latest/user-guide/tasks/manage-environments.html#activating-an-environment))?
> [@Joaquim](#):
>
> Where does conda stores the GMT binaries on Linux?
Mine is under `/home/username/miniconda3/envs/pygmt/bin`. There should be a `$CONDA_PREFIX` environment variable which points to the first part of that path (`/home/username/miniconda3/envs/pygmt`) you can use (once the conda env is activated) that points to the right place.
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 15, 2021, 2:09pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/6 "2021-05-15T14:09:38Z")
Who takes care of building GMT for Conda? Are you guys? It seems to be on different versions for different distros. While it worked in the Ubuntu20 used by the CI, it errors on a CentOS 8 with
```auto
[jluis@fct-gmt bin]$ ldd ./gmt
...
libnsl.so.1 => not found
librttopo.so.1 => /home/jluis/.julia/conda/3/bin/./../lib/./././librttopo.so.1 (0x00007f23368f1000)
libcharset.so.1 => /home/jluis/.julia/conda/3/bin/./../lib/./././libcharset.so.1 (0x00007f23368ec000)
libquadmath.so.0 => /home/jluis/.julia/conda/3/bin/./../lib/././libquadmath.so.0 (0x00007f23368b2000)
```
Another error that I get, this time in Ubuntu, is
```auto
PROJ4: Error During Test at /home/runner/work/GMT.jl/GMT.jl/test/test_proj4.jl:3
Got exception outside of a @test
could not load symbol "pj_get_spheroid_defn":
/home/runner/.julia/conda/3/lib/././libproj.so.22: undefined symbol: pj_get_spheroid_defn
```
but the same test works fine when the PROJ4 lib was installed with apt-get
---
### Author:  [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)
#### Post date: [May 16, 2021, 10:23pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/7 "2021-05-16T22:23:54Z")
> [@Joaquim](#):
>
> Who takes care of building GMT for Conda? Are you guys?
The builds are semi-automated. I’d ask @seisman or @leouieda who are maintainers of the repo, I just contribute to the conda gmt-feedstock once in a while.
> [@Joaquim](#):
>
> While it worked in the Ubuntu20 used by the CI, it errors on a CentOS 8 with
The Linux build script is at [gmt-feedstock/recipe/build.sh at main · conda-forge/gmt-feedstock · GitHub](https://github.com/conda-forge/gmt-feedstock/blob/master/recipe/build.sh). I don’t see any mention of `libnsl` or `libproj` in that script, so maybe we need to add it into the build flag somehow?
Looking under [gmt-feedstock/recipe/meta.yaml at main · conda-forge/gmt-feedstock · GitHub](https://github.com/conda-forge/gmt-feedstock/blob/master/recipe/meta.yaml), `PROJ` isn’t actually listed as a dependency (perhaps it should be) so that could be why it isn’t being picked up. Could you please provide the contents of the `test_proj4` script (preferably a GMT C equivalent), and we’ll try to add it to the test suite while fixing this issue.
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 16, 2021, 10:48pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/8 "2021-05-16T22:48:07Z")
`libproj` is a GDAL dependency (one can’t build GDAL nowadays without PROJ) but the `libnsl` is new to me. It’s certainly a dependency of a dependency but I’ve never seen it before.
Regarding `test_proj4`, it’s a [Julia test](https://github.com/GenericMappingTools/GMT.jl/blob/master/test/test_proj4.jl) that exercises wrapping `libproj` directly from Julia. Don’t know how to make it in other languages but it’s quite strange that it fails with that error message that means the mentioned symbol is not in the proj shared lib, which is quite suspicious.
---
### Author:  [@weiji14](https://forum.generic-mapping-tools.org/u/weiji14)
#### Post date: [May 16, 2021, 11:04pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/9 "2021-05-16T23:04:27Z")
> [@Joaquim](#):
>
> `libproj` is a GDAL dependency (one can’t build GDAL nowadays without PROJ)
Actually now that you mentioned it, running `conda list` shows `proj=8.0.0` installed in my gmt conda environment (which was probably pulled in by GDAL, I have `gdal=3.2.2` installed). What versions do you have installed? Not sure what to do about the undefined symbol though, maybe check the conda PROJ feedstock build scripts at [GitHub - conda-forge/proj.4-feedstock: A conda-smithy repository for proj.4.](https://github.com/conda-forge/proj.4-feedstock).
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 16, 2021, 11:20pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/10 "2021-05-16T23:20:15Z")
The problem to investigate this is that it happens in the CI machine and Conda doesn’t seem to install the same versions on different distros and the number of problems don’t stop and I can’t go to them all. Now is Mac that decides that `otool -L gmtlib.dylib` on the Conda build lib returns `@rpath/libname` instead of the true full name of the lib.
Unix is nuts
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 17, 2021, 2:44pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/11 "2021-05-17T14:44:39Z")
Apparently an error that many others have suffered too. Seems that some `libc` distribute it others not …
>
>
> With Fedora 28 (atomic workstation) I see the following error:
> \`\`\`
> ./Plex\_Medi…a\_Player\_2.11.0.867-f27f8d2a\_x64.AppImage
> /tmp/.mount\_Plex\_MF3VTwG/usr/bin/plexmediaplayer: error while loading shared libraries: libnsl.so.1: cannot open shared object file: No such file or directory
> \`\`\`
> However I have glibc installed
>
> \`\`\`
> Inactive requests:
> glibc (already provided by glibc-2.27-15.fc28.x86\_64)
> \`\`\`
---
### Author:  [@Joaquim](https://forum.generic-mapping-tools.org/u/Joaquim)
#### Post date: [May 19, 2021, 5:18pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/12 "2021-05-19T17:18:07Z")
But if I do (like they say in the above link)
```auto
sudo dnf install libnsl
```
next other libs in the Conda install are broken due to a GlibcXXX incompatibility.
---
### Author:  [@leouieda](https://forum.generic-mapping-tools.org/u/leouieda)
#### Post date: [May 27, 2021, 4:02pm UTC](https://forum.generic-mapping-tools.org/t/conda-gmt-build-is-unusable-in-julia-windows/1677/13 "2021-05-27T16:02:47Z")
Maybe we should think about including Proj as a GMT dependency on conda-forge and setting the proper path in the cmake build. Optional dependencies are difficult with compiled code like this and GMT may be finding the system Proj instead of the conda Proj.
@Joaquim I think conda-forge ships it’s own `libc` specifically to avoid the incompatibility errors. So mixing system libraries with conda-forge libraries will likely not work unless you use the same libc and gcc used for the conda-forge builds.
I have no idea what libnsl is but it’s not on conda-forge. I wonder if it’s a new dependency of Proj?