Trouble using Plots (on Linux)

The best would be to just remove the Plots package from the Julia distribution.

It is just a mess (according to the internet and all the other people with the same Qt problem and no real solution in sight).

And no I cannot install a newer Qt because in real life people often do not have super user rights and I don’t want to screw up my home directory with my own rogue /usr/bin.

When was the last time you had to worry that matplotlib on Python will not work?

Look to it from that perspective: would you develop Julia code using Plots for sharing with other people when you know that Plots may work or may not work on their platform (this does just not happen with matplotlib and Python).

using Plots

… version Qt_5.15 not found (required …) …

GKS: can’t connect to GKS socket application

GKS: Open failed in routine OPEN_WS
GKS: …

From this thread: Can't install Plots on julia-1.6.0 - #14 by mkitti

It seems that that kind of error may be solved by emptying the LD_LIBRARY_PATH variable before running Julia:


I just tested this in a pretty old machine (it runs the 3.10 kernel still), and Plots installed fine. Does that solves your issue?

(ps: that OS is Red Hat Enterprise Linux v7.2 - from 2014).

Plots in Julia is installed on my heavily guarded Linux distro (if it were not ‘using Plots’ would already raise an error).

I thought my post explained it:

julia> using Plots
Julia> plot(rand(23))

will throw the errors:

QT not found and the GKS error message (as shown in my original post).

(It would work on my OSX Ventura and my Macbook but this is beyond the point because here I am my own super user and can always make sure the BSD is up to date with various homebrew hacks).

I am not alone: Problem with Qt dependency of Plots.jl

I was having issues with Plots in that machine I mentioned, that is why I posted that. I believe you are not alone. What I did is:

  1. Empty the LD_LIBRARY_PATH as mentioned above.

  2. Install Plots in a new temporary environment (to be sure to avoid dependency conflicts).

  3. In that specific machine I don´t have access to a X server, thus I have disabled the X output with:

  1. plotted something, and saved the figure:

and that worked.

As a side note, from the bug report you mentioned, the issue seems to be with GR, thus maybe you can try another backend.

Doesn’t work.

It is really shocking how bad and absolutely confusing and confounded Julia “Plots” is. Honestly.

I am no Linux expert. Why should I have to worry and ponder over backends.

Plots should just work straight out of the box if I install it from within Julia.

This is what conda just does: install me all the packages I ask for and make sure they work (admittedly I only have got experience using conda on OSX and Linux so there may well be configurations where conda blows up).

But there is a silver lining on the horizon: using PyCall and then matplotlib works.

For me it almost always worked, that was an exception of a very old machine. What kind of Linux are you using?

You can switch the backend using:

using Plots

and that may work, if the problem is with GR.

Note that Plots is not part of Julia. It is a package that attempts to unify the interface of many plotting packages, GR being one of them and the default one to load.

Be aware that infuriating as it may be, it can also be that you are experiencing a rare failure case, which may not the experience of most people. Bugs exist, and they are bugs because the developers and testers didn’t experience them first round.

(this is offtopic, of course, but I’m sure you can find thousands of people trying to find how to solve matplotlib installation issues, it just happened that you were not of them).


Why not try some other plotting library instead of Plots if it does not work in your use cases?

As an example PlotlyLight.jl gives you access to the whole Plotly library.


Or simply PyPlot directly (GitHub - JuliaPy/PyPlot.jl: Plotting for Julia based on matplotlib.pyplot).

Okay pyplot() would work.

But isn’t this matplotlib?

I really think Plots is just confusing.

What is different now between pyplot() and not using pyplot()?

If I do not use pyplot() and lets assume for a moment using Plots would work what ‘plotting library’ would Plots use?

it uses GR by default.

As I said matplotlib and PyCall works.

Why the twist in the knickers:

What is the flagship plotting library in Julia?

I hedge a bet for Python it is matplotlib that the majority will use (at least for the bog standard 2d and 3d plots).

This also means when you use other peoples (scientific) Python code you will encounter matplotlib. And matplotlib just works out of the box with conda (OSX and Linux).

I have to repeat myself: what is the flagship plotting library for Julia that is supposed to work out of the box on all the major platforms (like matplotlib installed with conda).

This post was temporarily hidden by the community for possibly being off-topic, inappropriate, or spammy.

Have you tried Makie?


For me it is Plots, and I’ve been using it happily for some years now. Makie is becoming more and more important, and is quite powerful (I don´t like its load time).

While Plots is (still) probably the most used frontend for plotting, Julia does not have such a unified plotting approach, there are alternatives.

But probably you should not confound that with the bad experience you had with Plots, you probably just were not lucky (as lots of folks in the web are not lucky using matplotlib for a myriad of infuriating reasons as well).


Thanks for the link.

No I haven’t heard of Makie.

Having a plotting library just for one programming language may cause a whole raft of other problems.

That one can use Matplotlib in Julia is not a bad choice. It is just a fact of life that Python and subsequently matplotlib is one of the dominant tools in data exploration.

Why don’t the Julia stewards declare that pyplot shall be the main Julia plotting library?

This tends to indicate either a conflict in libraries, which may be triggered by LD_LIBRARY_PATH as @lmiq pointed out or this could be the consequence of a failed download of one or more artifacts.

You didn’t post a full log of the errors (julia stacktrace). A solution might be to delete the offending artifact directory and run pkg> instantiate (but we need your logs in order to be able to help).


This post was temporarily hidden by the community for possibly being off-topic, inappropriate, or spammy.

I understand your frustration :pray:t2:. But, just to offer some perspective: ggplot2 is a much more widely used plotting library for data exploration in many fields. I would rather walk backwards into a cactus :cactus: with a bare butt than use pyplot as my go-to plotting library. Don’t get me wrong: Pyplot is great for sure but i don’t like it and it’s really not productive for me. Long story short. I’m not sure pyplot is the preferred choice for the majority of people. So Julia marrying with a single library like that would be a bad move IMHO.

1 Like

This post was temporarily hidden by the community for possibly being off-topic, inappropriate, or spammy.


These issues do pop up from time to time, but they tend to fly under the radar because people will ask about them places like Slack (where you have ephemeral messages, lots of traffic in busy channels like #helpdesk and not many eyes on more obscure channels working against seeing such messages) or the issue tracker (e.g. 1, 2) where people who don’t have issues with plotting won’t be checking.

Now, 99% of people probably don’t have issues with the default plots backend. But if matplotlib runs successfully say, 99.9% of the time, one library will get more of this kind of issue reports than the other.