GeoArrays working in REPL, not working in Pluto.jl

[MBotman]

Hi,

I run into an issue using GeoArrays, (and ArchGDAL). When using these in the REPL all is working correctly. In Pluto.jl I get the following error on cell 2d7cfe40-eee1-11ea-32f4-8fff47db1e13 (see notebook below):

InitError: could not load library "[userdir].julia\artifacts\93a125a1f028ecc90665616e44072e4da65aea23\bin\libcurl-4.dll"

If I run the cell again the error becomes:

InitError: could not load library "[userdir].julia\artifacts\8ff6feb9234a4584dbdb04c7df64425d67e7a3d9\bin\libproj_7_0.dll"

3th time:

InitError: could not load library "[userdir].julia\artifacts\1a3f285b91b22d9081d1ec6a0af713214f300fd6\bin\libgdal-26.dll"

4th and 5th time:

InitError: could not load library "libgdal-26.dll"

6th time: No error on this cell! But the last error moved to the last cell.

System:
Windows 10
Julia 1.5.1

Notebook:

### A Pluto.jl notebook ###
# v0.11.12

using Markdown
using InteractiveUtils

# ╔═╡ 206fc6b0-eee1-11ea-1e61-dd3fe339bdf8
begin
	import Pkg
	Pkg.activate()
	Pkg.Registry.update()
end

# ╔═╡ 2d7cfe40-eee1-11ea-32f4-8fff47db1e13
begin
	Pkg.add("GeoArrays")
	using GeoArrays
end

# ╔═╡ 7da3dfde-eee3-11ea-06ab-6bfb1ccbdcb9
begin
	fn = download("https://github.com/yeesian/ArchGDALDatasets/blob/master/data/utmsmall.tif?raw=true")
	geoarray = GeoArrays.read(fn)
end

# ╔═╡ Cell order:
# ╠═206fc6b0-eee1-11ea-1e61-dd3fe339bdf8
# ╠═2d7cfe40-eee1-11ea-32f4-8fff47db1e13
# ╠═7da3dfde-eee3-11ea-06ab-6bfb1ccbdcb9

I'm new to Julia/Pluto.jl so unsure if this is a bug or an error on my part.

[fonsp]

Very strange errors! Can you try it with Pkg.activate(mktempdir()) instead of Pkg.activate()? Let me know how it goes

[MBotman]

Hi Fonsp, this was my initial code as well. But since I it worked in the REPL I tried using the standard environment.
Just tried your suggestion again to be sure, but it doesn't help.

Here is some more error output for the first error:

InitError: could not load library "[mywinuserdir]\.julia\artifacts\93a125a1f028ecc90665616e44072e4da65aea23\bin\libcurl-4.dll"

The specified procedure could not be found.

during initialization of module LibCURL_jll

    #dlopen#3(::Bool, ::typeof(Libdl.dlopen), ::String, ::UInt32)@Libdl.jl:109
    dlopen@Libdl.jl:109[inlined]
    __init__()@x86_64-w64-mingw32.jl:79
    _include_from_serialized(::String, ::Array{Any,1})@loading.jl:697
    _require_search_from_serialized(::Base.PkgId, ::String)@loading.jl:782
    _tryrequire_from_serialized(::Base.PkgId, ::UInt64, ::String)@loading.jl:712
    _require_search_from_serialized(::Base.PkgId, ::String)@loading.jl:771
    _require(::Base.PkgId)@loading.jl:1007
    require(::Base.PkgId)@loading.jl:928
    require(::Module, ::Symbol)@loading.jl:923
    top-level scope@Local: 3

[MBotman]

These issues might be related:
https://discourse.julialang.org/t/archgdal-jl-install-error/42761
https://www.gitmemory.com/issue/yeesian/ArchGDAL.jl/138/675006127

Versions I see in the console, while using Pluto:
[c9ce4bd3] + ArchGDAL v0.4.1
[add2ef01] + GDAL v1.1.4
[a7073274] + GDAL_jll v3.0.4+2
[2fb1d81b] + GeoArrays v0.3.1
[deac9b47] + LibCURL_jll v7.71.1+0
[58948b4f] + PROJ_jll v7.0.1+0
...

In REPL running Pkg.status() gives:
[c9ce4bd3] ArchGDAL v0.4.1
[2fb1d81b] GeoArrays v0.3.1
... (Not sure how to display the dependencies of these packages)

Hope this helps. If you believe the problem is with the ArchGDAL package please let me know.

[fonsp]

Does it work in the REPL if you do Pkg.activate(mktempdir()) first? Package loading issues are much easier to debug if you do Pkg.activate(mktempdir()).

If this doesn't work in the REPL:

begin
	import Pkg
	Pkg.activate(mktempdir())
	Pkg.Registry.update()
end

# ╔═╡ 2d7cfe40-eee1-11ea-32f4-8fff47db1e13
begin
	Pkg.add("GeoArrays")
	using GeoArrays
end

# ╔═╡ 7da3dfde-eee3-11ea-06ab-6bfb1ccbdcb9
begin
	fn = download("https://github.com/yeesian/ArchGDALDatasets/blob/master/data/utmsmall.tif?raw=true")
	geoarray = GeoArrays.read(fn)
end

then you should post this script and the error in an issue to GeoArrays

[MBotman]

It does work in the REPL using Pkg.activate(mktempdir())

[fonsp]

Did the error also disappear on Pluto?

[MBotman]

I still have the error in Pluto.
It is not possible to get the error in the REPL

[MBotman]

I have run the following code in the REPL and in a Notebook and compared the package directories.
There is no difference between the two Manifests.toml en Project.toml files

import Pkg
Pkg.activate(mktempdir())
Pkg.add("GeoArrays")
using GeoArrays

I will ask around today to see if someone can replicate this error to check if it is not just my machine.
Not sure on how to continue after that.

[felixcremer]

I tried to reproduce this on linux and loading GeoArrays works in Pluto for me.
You can use Pkg.status(mode=PKGMODE_MANIFEST) to get all dependencies.
Have you tested, whether you can load the GDAL.jl package?
I would suspect that it is a problem with the GDAL binary dependencies.

[fonsp]

sprint() do io
	Pkg.status(mode=Pkg.PKGMODE_MANIFEST, io=io)
end |> Text

inside Pluto

[MBotman]

(updated to latest Pluto: v0.11.14)

You are right it is the GDAL package, running the following triggers the error:

begin
	import Pkg
	Pkg.activate(mktempdir())
	Pkg.add("GDAL")
	using GDAL
end

Result of the manifest code (both REPL and Pluto give the same result):

  [fa961155] CEnum v0.4.1
  [add2ef01] GDAL v1.1.4
  [a7073274] GDAL_jll v3.0.4+2
  [d604d12d] GEOS_jll v3.8.1+0
  [aacddb02] JpegTurbo_jll v2.0.1+2
  [deac9b47] LibCURL_jll v7.71.1+0
  [29816b5a] LibSSH2_jll v1.9.0+3
  [89763e89] Libtiff_jll v4.1.0+1
  [d3a379c0] LittleCMS_jll v2.9.0+0
  [c8ffd9c3] MbedTLS_jll v2.16.8+0
  [14a3606d] MozillaCACerts_jll v2020.7.22+0
  [643b3616] OpenJpeg_jll v2.3.1+0
  [58948b4f] PROJ_jll v7.0.1+0
  [76ed43ae] SQLite_jll v3.32.3+0
  [83775a58] Zlib_jll v1.2.11+16
  [3161d3a3] Zstd_jll v1.4.5+1
  [b53b4c65] libpng_jll v1.6.37+5
  [8e850ede] nghttp2_jll v1.40.0+2
  [2a0f44e3] Base64
  [ade2ca70] Dates
  [b77e0a4c] InteractiveUtils
  [76f85450] LibGit2
  [8f399da3] Libdl
  [56ddb016] Logging
  [d6f4376e] Markdown
  [44cfe95a] Pkg
  [de0858da] Printf
  [3fa0cd96] REPL
  [9a3f8284] Random
  [ea8e919c] SHA
  [9e88b42a] Serialization
  [6462fe0b] Sockets
  [cf7118a7] UUIDs
  [4ec0a83e] Unicode

I am still looking for someone to replicate this on windows, I hope to have more info tomorrow.

[fonsp]

This does not sound like an issue with Pluto (nor like something that I can help with).

[kongdd]

@MBotman I got the same error. Any solution?

[MBotman]

@kongdd Unfortunately no, I never found a solution

[visr]

I am still looking for someone to replicate this on windows

I just tried, and I could not reproduce on latest Pluto with the latest GDAL build, GDAL_jll v3.0.4+7. If you still have the problem, it's maybe best to open a new issue on https://github.com/JuliaGeo/GDAL.jl, since Pluto is an unlikely culprit here.

There have been moments in the past that the GDAL build broke, in fact it was broken this week on some platforms until an hour ago. It should be getting more robust though, but it is a quite complex build. The good thing is that we have control over the environment, so if you get DLL errors from GDAL.jl, it's best to submit an issue such that we can fix it.