Launching GKSTerm failed.

[sje30]

On my mac, I now can't seem to get GR started:

julia> versioninfo()
Julia Version 0.5.0
Commit 3c9d753 (2016-09-19 18:14 UTC)
Platform Info:
  System: Darwin (x86_64-apple-darwin13.4.0)
  CPU: Intel(R) Core(TM) i7-4850HQ CPU @ 2.30GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Haswell)
  LAPACK: libopenblas64_
  LIBM: libopenlibm
  LLVM: libLLVM-3.7.1 (ORCJIT, has well)


julia> using GR
INFO: Recompiling stale cache file /Users/stephen/.julia/lib/v0.5/GR.ji for module GR.

julia> GR.plot(rand(10))
2016-10-29 17:12:48.727 julia[9174:376773] Launching GKSTerm failed.

This is with the latest version of GR installed after first deleting ~/.julia/v0.5

any clues?

[jheinen]

What happens if you manually start GKSTerm:
open /Users/stephen/.julia/v0.5/GR/deps/gr/Applications/GKSTerm.app
or:
/Users/stephen/.julia/v0.5/GR/deps/gr/Applications/GKSTerm.app/Contents/MacOS/GKSTerm

On rare cases, I've seen error messages like "... is not a valid executable" (for the first method, which is used by GR - the second method always worked).

If you can reproduce this behavior, please try to copy the GKSTerm.app to another location and back again.

Sounds weird, but I have not figured out yet, what the real problem is ...

[sje30]

Thanks, indeed the first method failed; the second work.

~ $ open /Users/stephen/.julia/v0.5/GR/deps/gr/Applications/GKSTerm.app
The application cannot be opened because its executable is missing.
~ $ /Users/stephen/.julia/v0.5/GR/deps/gr/Applications/GKSTerm.app/Contents/MacOS/GKSTerm

however, moving the application to another location and back to the folder didn't work.

~/.julia/v0.5/GR/deps/gr/Applications $ mv GKSTerm.app /tmp
~/.julia/v0.5/GR/deps/gr/Applications $ mv /tmp/GKSTerm.app .
~/.julia/v0.5/GR/deps/gr/Applications $ open GKSTerm.app
The application cannot be opened because its executable is missing.

[jheinen]

Is GKSTerm.app listed in System Preferences => Security and Privacy => Allow apps downloaded from:?

[sje30]

When I visit that sys preference, I don't see a list of allowed apps, but I have the item checked "Mac App store and identified developers".

In the meantime, I tried the following:

/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f GKSTerm.app/

and now I get plots in Julia, hurrah! Not sure why, I just took the above from: http://stackoverflow.com/questions/2182040/the-application-cannot-be-opened-because-its-executable-is-missing/16546673#16546673

[jheinen]

Thanks for your help ! 👏 👍

I will add this command to the build.jl script in the next release.

[sje30]

ok, fingers crossed! Thanks for your help (and the package!).

[ssfrr]

I just had this issue, and copying the app back and forth worked for me.

[alanedelman]

I seem to have run into the same issue, but using JuilaPro
The only thing is I keep running into that it's looking into /usr/local/gr
where my stuff is stored in
JuliaPro-0.5.0.4.app/Contents/Resources/pkgs-0.5.0.4/v0.5/GR/deps/gr

how can i set a variable to where to point?

GKS: file open error (/usr/local/gr/fonts/gksfont.dat)
Unable to load GR framework runtime environment
/usr/local/gr/lib/libGR.so: No such file

[alanedelman]

just a followup when I created a symbolic link all was good

ln -s /Applications/JuliaPro-0.5.0.4.app/Contents/Resources/pkgs-0.5.0.4/v0.5/GR/deps/gr /usr/local/gr

[jheinen]

@alanedelman : There's probably some "old" GR distribution on your machine. I'd suggest to rm -rf /usr/local/gr (if you don't need the for other development environments, like C/C++ or Python), and then force a download of the most recent GR binaries (within Julia):

ENV["GRDIR"]=""
Pkg.build("GR")

That should fix the problem.

[juliohm]

@jheinen this issue is affecting visual regression tests on Travis for the OSX build only: https://travis-ci.org/juliohm/GeoStats.jl/jobs/263332499

What can be done in this case?

[jheinen]

I have absolutely no idea, why GKSTerm can't be loaded. The build script should fix this problem:

app = joinpath("gr", "Applications", "GKSTerm.app")
run(`/System/Library/Frameworks/CoreServices.framework/Frameworks/LaunchServices.framework/Support/lsregister -f $app`)

I just checked GR on Travis and it worked: https://travis-ci.org/jheinen/GR.jl/jobs/260065240

[juliohm]

@jheinen you mean that I need to add these lines to my Travis config file? I have no idea what is happening either, I will restart the build once again to see the problem persists.

[jheinen]

... this is normally done during the GR build phase.

[juliohm]

I restarted the build and the error seems to be unrelated now: https://travis-ci.org/juliohm/GeoStats.jl/jobs/263332499

The Travis OSX is quite unpredictable, I wish I had access to a OSX to test GeoStats.jl locally.

[juliohm]

The error is persistent on OSX: https://travis-ci.org/juliohm/GeoStats.jl/jobs/263759923#L254 😢

Could you please elaborate on what is GKSTerm and what is its relation to GR?

I was looking into deps/build.jl and it seems that you are not using the BinDeps.jl package. Is there a reason for not using it? I wonder if that is a binary dependency issue on OSX only.

[jheinen]

GKSTerm is part of GR and the default output device on macOS X. The tests in GeoStats seem to use GR in interactive mode, which can't work in a headless environment like Travis:

using Plots; gr(size=(600,400))

You could set the default output device to PDF:

ENV["GKSwstype"]="pdf"; using Plots; gr(size=(600,400))

[juliohm]

@jheinen all the tests were working before on MacOSX with GR, this error started happening recently.

What you mean by tests in interactive mode? I am following test standards according to my .travis.yml?

[jheinen]

There is no "terminal" in Travis, as it runs on a headless node. So you can't connect to a graphics terminal (GKSTerm.app). Please follow the instructions above.

May be it worked some time ago, when GR was not the default backend.

[juliohm]

I am sure it was working with GR. I was using it already for my tests since JuliaCon.

I wonder if my visual regression tests with VisualRegressionTests.jl will be affected by setting ENV["GKSwstype"]="pdf"?

[juliohm]

Any recent change on the default output device in GR? I can't see another reason for this build failure on Travis OSX. What I can tell you for sure is that the build was successful some days ago.

[jheinen]

It's probably related to this commit - I don't know. All tests are passing in GR and in Plots.

Tom's visual regression tests are done using PNGs. IMO the above workaround should work ... Did you try it?

[juliohm]

For reference, you can check the build history of GeoStats.jl here and check that the build number 202 was successful with GR 5 days ago: https://travis-ci.org/juliohm/GeoStats.jl/builds/262532068

I'd rather not change my test data, the issue is problably in Plots.jl configuration. But I can try the PDF output when I have some time this week. I am working on something that is demanding a lot of my time now.

[jheinen]

... you don't have to change your test data - just change this single line in 'build.jl.

[jheinen]

I'll install GeoStats.jl and run the tests on my iMac when I'm back in office (tomorrow).

[juliohm]

Thank you @jheinen, that would be super helpful 🙂 I am trying to avoid polluting the commit history of GeoStats.jl for just checking the Travis build. I don't think this issue is serious though, probably something very simple is missing in the Plots.jl setup.

[jheinen]

There seems to be a problem with the lsregister command on macOS X.

In rare cases, opening the GKSTerm application by URL failed. Unfortunately, this behaviour was not reproducible - even rebuilding the LaunchServices database or repeatedly registering the GKSTerm application (using lsregister) may not help.

Launching the GKSTerm binary using the NSTask mechanism, however, always seems to work !?

I patched the current Darwin run-time - please re-trigger the Travis CI session.

[juliohm]

Thanks @jheinen, that's awesome! 😊 The build status is green again. I appreciate your help.

Have a good productive week.

[ktitimbo]

Does this issue appear again for Apple Silicon? I got:
Could not locate GKSTerm.app

any workaround for that?

[jheinen]

You are probably using a very old GR version. Could you provide some version information (macOS, Julia, GR)?

[ktitimbo]

macOS Sonoma 14.3

Julia Version 1.10.0
Commit 3120989f39b (2023-12-25 18:01 UTC)
Build Info:
Official https://julialang.org/ release
Platform Info:
OS: macOS (arm64-apple-darwin22.4.0)
CPU: 12 × Apple M2 Pro
WORD_SIZE: 64
LIBM: libopenlibm
LLVM: libLLVM-15.0.7 (ORCJIT, apple-m1)
Threads: 1 on 8 virtual cores

Status ~/.julia/environments/v1.10/Project.toml
[91a5bcdd] Plots v1.40.0

Status ~/.julia/environments/v1.10/Project.toml
[28b8d3ca] GR v0.73.1

and I am using Visual Studio Code.

Pretty much everything up-to-date, i believe

[jheinen]

Could you pls try to start Julia with an explicit output device?

GKSwstype=gksqt julia

For any reason, GKSwstype points to workstation type 400 (GKSTerm) in your environment - this driver is not distributed with the BinaryBuilder GR release.

[ktitimbo]

Thanks,

after starting Julia with the above command, it works!

Any suggestion to fix my environment?
How could I make it work when using Visual Studio Code/VSCodium?

[jheinen]

Is GKSwstype set in your VSCode environment? If so, could find out where it is set? Unfortunately, I can't reproduce this behaviour on my laptop. Are you using plain GR or Plots ?

[simonsteiger]

I am running into the same issue from the REPL. Launching Julia with GKSwstype=gksqt julia solves the issue for that session. I used StatsPlots when first running into this issue.

(@v1.10) pkg> status
Status `~/.julia/environments/v1.10/Project.toml`
  [5fb14364] OhMyREPL v0.5.23
  [c3e4b0f8] Pluto v0.19.37
  [295af30f] Revise v3.5.13
  [40b0751a] SRQ v1.0.0-DEV `~/.julia/dev/SRQ`
  [f3b207a7] StatsPlots v0.15.6
  [fce5fe82] Turing v0.30.3

The issue is not present if I launch julia in a project with the following Project.toml.

(atoll-seabirds) pkg> status
Status `~/Documents/GitHub/atoll-seabirds/Project.toml`
⌃ [336ed68f] CSV v0.10.11
⌃ [13f3f980] CairoMakie v0.11.5
  [8be319e6] Chain v0.5.0
  [35d6a980] ColorSchemes v3.24.0
  [5ae59095] Colors v0.12.10
  [a93c6f00] DataFrames v1.6.1
  [5078a376] LazyArrays v1.8.3
  [6f286f6a] MultivariateStats v0.10.2
  [bac558e1] OrderedCollections v1.6.3
  [a68b5a21] ParetoSmooth v0.7.7
  [7f36be82] PosteriorStats v0.2.0
  [37e2e3b7] ReverseDiff v1.15.1
⌅ [2913bbd2] StatsBase v0.33.21
  [4c63d2b9] StatsFuns v1.3.0
  [f3b207a7] StatsPlots v0.15.6
⌅ [fce5fe82] Turing v0.24.4
⌃ [0db1332d] TuringBenchmarking v0.2.0
  [37e2e46d] LinearAlgebra

[jheinen]

Sorry, still can't reproduce that behaviour. I set up the above environment, and GR uses the Qt backend (GKS QtTerm). Same in a fresh Julia 1.11.0-DEV.1398 environment:

(@v1.11) pkg> add OhMyREPL Pluto Revise StatsPlots Turing
(@v1.11) pkg> status
Status `~/.julia/environments/v1.11/Project.toml`
  [5fb14364] OhMyREPL v0.5.23
  [c3e4b0f8] Pluto v0.19.37
  [295af30f] Revise v3.5.13
  [f3b207a7] StatsPlots v0.15.6
  [fce5fe82] Turing v0.30.3

[ktitimbo]

The issue appears in both Plots and GR. In the console, and Visual Code's REPL, without GKSwstype=gksqt julia I obtained

`
Status ~/.julia/environments/v1.10/Project.toml
[28312eec] Alert v1.2.0
[336ed68f] CSV v0.10.12
[5ae59095] Colors v0.12.10
[a93c6f00] DataFrames v1.6.1
[0c46a032] DifferentialEquations v7.12.0
[28b8d3ca] GR v0.73.1
[b964fa9f] LaTeXStrings v1.3.1
[2774e3e8] NLsolve v4.5.1
[b946abbf] NaNStatistics v0.6.34
[429524aa] Optim v1.9.1
[91a5bcdd] Plots v1.40.0
[87c4ff3e] WignerD v0.1.3
[37e2e46d] LinearAlgebra
[44cfe95a] Pkg v1.10.0

`

I don't know how to check where GKSwstype is

[jheinen]

I will force the GKSwstype setting to gksqt in the next release.

[jheinen]

The problem is fixed in GR 0.73.2

[ktitimbo]

Thank you!
Everything runs well