I’m getting following error, when I tried to install the GMT package into global packages.
Failed to precompile GMT [5752ebe1-31b9-557e-87aa-f909b540aa54] to /Users/cbandara/.julia/compiled/v1.6/GMT/jl_rcWYt7.
ERROR: LoadError: SystemError: opening file “/Users/cbandara/.julia/packages/GMT/1kBBX/deps/deps.jl”: No such file or directory
My Julia version: 1.6
OS: Mac Ventura 13.6
Mac Chip: Apple M1 Pro
I’m not seeing how it would it mater for this but why don’t you use a more recent Julia version? The just released 1.10rc is so much faster in compiling and loading the pre-compiled cache files.
BTW, the GMT.jl Project.toml has julia = "1.7" as minimal version.
Yeah, I know we have a requirement to build some functionality to a legacy API, unfortunately, that API functionality relies on the Julia 1.6 version.
Oh, is there a anyway around this to install a compatible version for Julia 1.6 ?
Try to see what version was the last one supporting Julia 1.6 (look at the commit history of the project.toml on GitHub) and install that version (by specifying it in the project.toml.of your environment).
e.g. How to install a specific version of a package with Pkg.add(“…”)
You can try also to edit the GMT.jl Project.toml file and change the julia = "1.7" under the compat section to julia = "1.6" and see if it works.
The error you are seeing means that the build step didn’t run successfully. You could either try ] build GMT or post the full log.
In either case when asking for help it’s often beneficial to post the version of the packages involved.
I tried installing the compatible version for julia 1.6 (JuliaHub), Still the same issue happens. Package version that I’m trying is 0.44.8
So what do you get when you do:
import Pkg; Pkg.build("GMT")
For me:
(@v1.6) pkg> activate --temp
Activating new environment at `/tmp/jl_z8FBKS/Project.toml`
(jl_z8FBKS) pkg> add GMT@0.44.8
Updating registry at `~/.julia/registries/General`
Updating git-repo `https://github.com/JuliaRegistries/General.git`
Resolving package versions...
Installed VersionParsing ─ v1.3.0
Installed Conda ────────── v1.9.1
Installed GMT ──────────── v0.44.8
Updating `/tmp/jl_z8FBKS/Project.toml`
[5752ebe1] + GMT v0.44.8
Updating `/tmp/jl_z8FBKS/Manifest.toml`
[8f4d0f93] + Conda v1.9.1
[a8cc5b0e] + Crayons v4.1.1
[9a962f9c] + DataAPI v1.15.0
[e2d170a0] + DataValueInterfaces v1.0.0
[5752ebe1] + GMT v0.44.8
[82899510] + IteratorInterfaceExtensions v1.0.0
[682c06a0] + JSON v0.21.4
[b964fa9f] + LaTeXStrings v1.3.0
[bac558e1] + OrderedCollections v1.6.2
[69de0a69] + Parsers v2.7.2
[aea7be01] + PrecompileTools v1.2.0
[21216c6a] + Preferences v1.4.1
[08abe8d2] + PrettyTables v2.2.8
[189a3867] + Reexport v1.2.2
[66db9d55] + SnoopPrecompile v1.0.3
[892a3eda] + StringManipulation v0.3.4
[3783bdb8] + TableTraits v1.0.1
[bd369af6] + Tables v1.11.1
[81def892] + VersionParsing v1.3.0
[0dad84c5] + ArgTools
[56f22d72] + Artifacts
[2a0f44e3] + Base64
[ade2ca70] + Dates
[f43a241f] + Downloads
[b77e0a4c] + InteractiveUtils
[b27032c2] + LibCURL
[76f85450] + LibGit2
[8f399da3] + Libdl
[37e2e46d] + LinearAlgebra
[56ddb016] + Logging
[a63ad114] + Mmap
[44cfe95a] + Pkg
[de0858da] + Printf
[3fa0cd96] + REPL
[9a3f8284] + Random
[ea8e919c] + SHA
[9e88b42a] + Serialization
[6462fe0b] + Sockets
[2f01184e] + SparseArrays
[10745b16] + Statistics
[fa267f1f] + TOML
[a4e569a6] + Tar
[cf7118a7] + UUIDs
[4ec0a83e] + Unicode
[deac9b47] + LibCURL_jll
[29816b5a] + LibSSH2_jll
[c8ffd9c3] + MbedTLS_jll
[14a3606d] + MozillaCACerts_jll
[83775a58] + Zlib_jll
[8e850ede] + nghttp2_jll
[3f19e933] + p7zip_jll
Building Conda → `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/8c86e48c0db1564a1d49548d3515ced5d604c408/build.log`
Building GMT ──→ `~/.julia/scratchspaces/44cfe95a-1eb2-52ea-b672-e2afdf69b78f/5968385e86d9c119db96d05e41df420c245f73da/build.log`
The building GMT step takes quite a bit and looking at the log that seems to be a Conda issue…
Version 0.44 still used the Conda install, not the GMT_jll artifacts as it does now. Why don’t you try what I suggested?
That approach you suggested to edit the Julia version in the Project.toml right ? This would help us to work in local env if that works, but in the production we have dockerize the application under based image which has the julia 1.6, then how do we do that version update ?
You seem to be still building the old 0.44 version (current one does not use Conda anymore). And you might have hit Bit/Bool syntax in statplots.jl : "|" is not a unary operator · Issue #1223 · GenericMappingTools/GMT.jl · GitHub but can’t be sure because you only show a small bit of the stack trace. Don’t use screen-shots, just copy the text message.
Anyway, try the master version. I’ve lowered the compat requirement to 1.6 and fixed the issue #1223 but there is at least one place where the stack function is used and that one requires Julia1.9. Don’t know if that bothers the using if that function is not called.
You are out of luck for compiling current GMT.jl version (build error)
But if you want to give it a try, you can make GMT.jl work with a local GMT (the C program) build by following this recipe.
# The file deps/deps.jl is created by compile from the deps/build.jl
# On Windows we use a system wide GMT if it is found from path or install it from a GMT installer. It is a MSVC binary.
# On Unix the default is to use the GMT_jll artifact. However this can be changed to use a system wide GMT installation.
# To swap to a system wide GMT installation, do (in REPL):
# 1- ENV["SYSTEMWIDE_GMT"] = 1;
# 2- import Pkg; Pkg.build("GMT")
# 3- restart Julia
#
# Note the above will work up until some other reason triggers a Julia recompile, where the JLL artifacts
# will be used again. To make the ENV["SYSTEMWIDE_GMT"] = 1 solution permanent, declare a "SYSTEMWIDE_GMT"
# environment variable permanently in your .bashrc (or whatever).
Hmmmm. My requirement is to use this logic in a production server. But would it work on a Ubuntu machine ?
Julia 1.6 support for Apple M1 is not great. At that version I might recommend the the Intel binaries over the native ARM binaries. We only upgraded Apple M1 to Tier 1 support status with Julia 1.9. An Ubuntu Linux machine wo I ld probably have better support at Julia 1.6.
What is the Julia 1.6 API that is keeping you at that version?
Also, have you been using a fresh Julia environment for this install?
@mkitti , Yes I tried with a fresh Julia env too. It’s an internal API that we have built, there are lots of legacy stuff we have built around that Julia 1.6 version.