# Issues with Plots and Libtiff\_jll

**URL:** <https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134>\
**Category:** General Usage\
**Tags:** plotting, binarybuilder, yggdrasil\
**Created:** [September 22, 2023, 5:03am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134 "2023-09-22T05:03:34Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![gzagatti](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@gzagatti](https://discourse.julialang.org/u/gzagatti)\
**Post date:** [September 22, 2023, 5:03am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134/1 "2023-09-22T05:03:34Z")

</div>

I recently updated the `Plots` package in my working environment just to find that I couldn’t plot anymore as the installation was suddenly broken.

```julia
> using Plots
...
WARNING: Method definition airyai(ColorTypes.Color{T, 1} where T) in module ColorVectorSpace at /home/gzagatti/.julia/packages/ColorVectorSpace/QI5vM/src/ColorVectorSpace.jl:315 overwritten in module SpecialFunctionsExt at /home/gzagatti/.julia/packages/ColorVectorSpace/tLy1N/ext/SpecialFunctionsExt.jl:15.
  **incremental compilation may be fatally broken for this module**...
> plot(1)
GKS: libtiff.so.6: cannot open shared object file: No such file or directory

```

I found out the issue was that when `Plots` was updated so was `Libtiff_jll`. Now `Libtiff_jll` links to version `4.5` of `libtiff` which is not available on the official `apt` repositories for Ubuntu 22 as you can see from [here](https://packages.ubuntu.com/search?keywords=libtiff&searchon=names).

I considered the following options, but I am not completely satisfied with any of them.

1. Add a compat entry to my `Project.toml` environment as described in [this discourse thread](https://discourse.julialang.org/t/specify-compat-for-jll-binary-libtiff-jll/100713).

2. Install `libtiff` with Homebrew and modify `ENV` in `startup.jl`:

At the end I went for option (3) because that is what worked and I didn’t need to modify every single `Project.toml` that I came accross. However, I would prefer to go for option (2) because at least everything remains within Julia. It would be great if Julia could pick the modifications in `ENV` at startup.

Even better, it would be great to have a file in `~/.julia/config` that tells Julia about our local development constraints.

It would be great to hear your thoughts on this issue. Perhaps someone has a better solution or I have missed some obvious configuration.

Thanks for all the great work on [`BinaryBuilder.jl`](https://github.com/JuliaPackaging/BinaryBuilder.jl) and [`Yggdrasil`](https://github.com/JuliaPackaging/Yggdrasil) which I had no idea it existed until I came across this error.

---

<div class="post-metadata">

**Author:** ![GunnarFarneback](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/gunnarfarneback/32/1827_2.png) [@GunnarFarneback](https://discourse.julialang.org/u/GunnarFarneback)\
**Post date:** [September 22, 2023, 7:30am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134/2 "2023-09-22T07:30:21Z")

</div>

> [@gzagatti](#):
>
> I found out the issue was that when `Plots` was updated so was `Libtiff_jll`. Now `Libtiff_jll` links to version `4.5` of `libtiff` which is not available on the official `apt` repositories for Ubuntu 22 as you can see from [here](https://packages.ubuntu.com/search?keywords=libtiff&searchon=names).

There clearly is a bug here but it’s not that some specific version of libtiff is missing from your system libraries. It would be helpful to be able to reproduce this. I’m also on Ubuntu 22 and this works:

```julia
/tmp$ mkdir test_environment
/tmp$ cd test_environment/
/tmp/test_environment$ julia --project=.
               _
   _ _ _(_)_ | Documentation: https://docs.julialang.org
  (_) | (_) (_) |
   _ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` | |
  | | |_| | | | (_| | | Version 1.9.3 (2023-08-24)
 _/ |\ __'_|_|_|\__'_| | Official https://julialang.org/ release
|__/ |

(test_environment) pkg> add Plots Libtiff_jll
[...]

(test_environment) pkg> status
Status `/tmp/test_environment/Project.toml`
  [91a5bcdd] Plots v1.39.0
  [89763e89] Libtiff_jll v4.5.1+1

julia> using Plots, Libtiff_jll

julia> plot(1) # works

julia> Libtiff_jll.libtiff_path
"/home/gunnar/.julia/artifacts/e18a60e84fd8aefa967cb9f1d11dc6cbd9cac88b/lib/libtiff.so"

```

> [@gzagatti](#):
>
> Even better, it would be great to have a file in `~/.julia/config` that tells Julia about our local development constraints.

The mechanism to point Julia to system or custom libraries is [8. Artifacts · Pkg.jl](https://pkgdocs.julialang.org/v1/artifacts/#Overriding-artifact-locations) but unless you have very specific needs it’s unlikely that this is something you want to explore.

> [@gzagatti](#):
>
> However, I would prefer to go for option (2) because at least everything remains within Julia.

Changing `ENV["LD_LIBRARY_PATH"]` inside julia happens much too late since that environment variable was read by the dynamic loader before starting julia.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [September 22, 2023, 7:41am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134/3 "2023-09-22T07:41:00Z")

</div>

GR\_jll correctly specifies the compat bound for Libtiff\_jll, so I’m missing what the problem could be:

> <https://github.com/JuliaPackaging/Yggdrasil/blob/a5d3d3af4d2ab59cc86a4f57c92c5fc9c2a3a833/G/GR/build_tarballs.jl#L99>

---

<div class="post-metadata">

**Author:** ![gzagatti](https://avatars.discourse-cdn.com/v4/letter/g/97f17d/32.png) [@gzagatti](https://discourse.julialang.org/u/gzagatti)\
**Post date:** [September 22, 2023, 9:25am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134/4 "2023-09-22T09:25:51Z")

</div>

Thank you both for your fast response.

@GunnarFarneback I followed your step-by-step `test_environment` without any issues. It turns out the problem involved more than the `Plots` and `Libtiff_jll`.

As I use Kitty as my terminal, I tend to pre-load a convenient package `KittyTerminalImages` in my startup script to display plots directly on the terminal (which is particularly convenient in a remote server). It turns out that `KittyTerminalImages` will install `Libtiff_jll` version `4.4` because it depends on `RSvg` which depends on `gdk_pixbuf_jll` which has a constraint on `Libtiff_jll`.

However, `KittyTerminalImages` is loaded from my base environment `@1.9` while `Plots` usually come from my working `Project.toml`. Therefore, to reproduce the bug you have to do the following:

```sh
> cd ~/.julia/environments/v1.9
> julia --startup-file=no
julia> ]
(@v1.9) pkg> add https://github.com/gzagatti/KittyTerminalImages.jl.git#inteporlation-update
...
julia> exit()
> cd test_environment
> julia --startup-file=no
julia> using KittyTerminalImages
julia> ]
(@v1.9) pkg> activate .
(test_environment) pkg>
julia> using Plots
...
WARNING: Method definition zeta(ColorTypes.Color{T, 1} where T) in module ColorVectorSpace at /home/gzagatti/.julia/packages/ColorVectorSpace/QI5vM/src/ColorVectorSpace.jl:315 overwritten in module SpecialFunctionsExt at /home/gzagatti/.julia/packages/ColorVectorSpace/tLy1N/ext/SpecialFunctionsExt.jl:15.
  **incremental compilation may be fatally broken for this module**

GKS: libtiff.so.6: cannot open shared object file: No such file or directory

```

Strangely enough, if I do the inverse I have no problems:

```sh
> cd test_environment
> julia --startup-file=no
julia> ]
(@v1.9) pkg> activate .
(test_environment) pkg>
julia> using Plots, KittyTerminalImages

```

Therefore, my strategy will be to stop pre-loading `KittyTerminalImages` and only load the package after `Plots` is loaded. A bit less convenient, but more elegant IMO.

In any case, I think we might have a bug here because each package should read its own artifact. But please correct me if I’m wrong.

---

<div class="post-metadata">

**Author:** ![giordano](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/giordano/32/2166_2.png) [@giordano](https://discourse.julialang.org/u/giordano)\
**Post date:** [September 22, 2023, 9:49am UTC](https://discourse.julialang.org/t/issues-with-plots-and-libtiff-jll/104134/5 "2023-09-22T09:49:23Z")

</div>

> [@gzagatti](#):
>
> In any case, I think we might have a bug here because each package should read its own artifact. But please correct me if I’m wrong.

I think the problem is that Pkg allows stacking incompatible environments.