Pkg.build fails with LoadError: Unable to open libLLVM! #29720

markleary · 2018-10-18T20:10:44Z

Using Julia 0.7.0 on RHEL 7.5. Julia was installed from julia-epel-7 repo referenced in the documentation (https://copr.fedorainfracloud.org/coprs/nalimilan/julia/). Building any package fails with:

ERROR: LoadError: LoadError: Unable to open libLLVM!

llvm6-libs.x86_64-6.0.0-4.el7 package was installed from the julia repo. This rpm installs libLLVM to /usr/lib64/llvm6/lib/. For some reason the build process does not find the lib. I worked around the issue by creating a symlink in /usr/lib64:

ln -s /usr/lib64/llvm6/lib/libLLVM-6.0.0.so /usr/lib64/libLLVM.so

With this symlink in place, packages build successfully.

Julia versioninfo():

Julia Version 0.7.0
Commit a4cb80f3ed (2018-08-08 06:46 UTC)
Platform Info:
  OS: Linux (x86_64-redhat-linux)
  CPU: Intel(R) Xeon(R) CPU E7-8880 v3 @ 2.30GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, haswell)

build log:

ERROR: LoadError: LoadError: Unable to open libLLVM!
Stacktrace:
 [1] error(::String) at ./error.jl:33
 [2] (::getfield(BinaryProvider, Symbol("#open_libllvm#114")))() at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/PlatformNames.jl:650
 [3] detect_cxx11_string_abi() at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/PlatformNames.jl:653
 [4] detect_compiler_abi() at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/PlatformNames.jl:666
 [5] top-level scope at none:0
 [6] include at ./boot.jl:317 [inlined]
 [7] include_relative(::Module, ::String) at ./loading.jl:1038
 [8] include at ./sysimg.jl:29 [inlined]
 [9] include(::String) at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/BinaryProvider.jl:1
 [10] top-level scope at none:0
 [11] top-level scope at none:2
in expression starting at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/PlatformNames.jl:683
in expression starting at /bbkinghome/mleary/.julia/packages/BinaryProvider/1nGWd/src/BinaryProvider.jl:12
ERROR: LoadError: Failed to precompile BinaryProvider [b99e7846-7c00-51b0-8f62-c81ae34c0232] to /bbkinghome/mleary/.julia/compiled/v0.7/BinaryProvider/ek6VZ.ji.
Stacktrace:
 [1] include(::String) at ./client.jl:398
 [2] top-level scope at none:0
in expression starting at /bbkinghome/mleary/.julia/packages/Rmath/Py9gH/deps/build.jl:1

julia-epel-7.repo

[julia-epel-7]
name=Copr repo for julia owned by nalimilan
baseurl=https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/epel-7-$basearch/
enabled=True
gpgcheck=True
gpgkey=https://copr-be.cloud.fedoraproject.org/results/nalimilan/julia/pubkey.gpg
skip_if_unavailable=True

The text was updated successfully, but these errors were encountered:

nalimilan · 2018-10-18T20:25:36Z

AFAIK this is fixed with 1.0.1. Why don't you update?

egnha · 2018-10-25T07:36:49Z

@nalimilan Even on 1.0.1, I run into a similar problem (ERROR: LoadError: LoadError: Unable to open libLLVM!) when attempting to build ZMQ and MBedTLS, as part of the IJulia build. Could you kindly point me to the fix?

moppymopperson · 2018-10-25T08:18:12Z

I'm having the same issue as @egnha, though I'm on Ubuntu 18.

nalimilan · 2018-10-26T18:22:09Z

@egnha I can't reproduce on Fedora 28 nor on Centos 7. What OS and what exact version of the package are you using?

Cc: @cdluminate for Debian/Ubuntu.

cdluminate · 2018-10-27T03:32:37Z

@nalimilan Cannot reproduce on both amd64 and ppc64el. Tested with julia version Debian ⛬ julia/1.0.1-2

cdluminate · 2018-10-27T03:40:05Z

Maybe something wrong with the shared lib / symlink /usr/lib/x86_64-linux-gnu/julia/libLLVM.so ?

These files / symlinks are included in the official binary tarball.

~/b/julia-1.0.0 ❯❯❯ find | rg LLVM
./lib/julia/libLLVM-6.0.so
./lib/julia/libLLVM.so
./lib/julia/libLLVM-6.0.0.so

nazywamsiepawel · 2018-10-29T10:38:29Z

I'm having the same issue on macOS Mojave, 10.14 with an anaconda setup and Julia v1.0.1

I create a new environment, install julia via conda install -c conda-forge julia

In order to access Julia via jupyter notebooks I do the following:

using Pkg Pkg.add("IJulia")

All goes fab,but then then opening jupyter notebook and selecting Julia yields the following:

Blosc not installed properly, run Pkg.build("ZMQ"), restart Julia and try again

Hoping for a successful resolution of the above, I run:

using Pkg Pkg.build("ZMQ")

Which slaps me back with the error that we are all experiencing here:

Error: Error buildingZMQ: │ ERROR: LoadError: LoadError: Unable to open libLLVM!

Is there anything wrong with the process I'm following? It's the first time I'm trying to get Julia to work with Jupyter Notebook.

Julia info

Julia Version 1.0.1 Platform Info: OS: macOS (x86_64-apple-darwin16.7.0) CPU: Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz WORD_SIZE: 64 LIBM: libopenlibm LLVM: libLLVM-6.0.0 (ORCJIT, skylake)

MaxBalashov · 2018-10-29T11:51:21Z

I'm having the same issue on macOS Mojave, 10.14 with an anaconda setup and Julia v1.0.1

I create a new environment, install julia via conda install -c conda-forge julia

In order to access Julia via jupyter notebooks I do the following:

using Pkg Pkg.add("IJulia")

All goes fab,but then then opening jupyter notebook and selecting Julia yields the following:

Blosc not installed properly, run Pkg.build("ZMQ"), restart Julia and try again

Hoping for a successful resolution of the above, I run:

using Pkg Pkg.build("ZMQ")

Which slaps me back with the error that we are all experiencing here:

Error: Error buildingZMQ: │ ERROR: LoadError: LoadError: Unable to open libLLVM!

Is there anything wrong with the process I'm following? It's the first time I'm trying to get Julia to work with Jupyter Notebook.

Julia info

Julia Version 1.0.1 Platform Info: OS: macOS (x86_64-apple-darwin16.7.0) CPU: Intel(R) Core(TM) i7-6920HQ CPU @ 2.90GHz WORD_SIZE: 64 LIBM: libopenlibm LLVM: libLLVM-6.0.0 (ORCJIT, skylake)

I also have such problem!

quentinlouis · 2018-11-01T12:04:10Z

@nazywamsiepawel Exactly the same problem for me !

rnevils · 2018-11-01T16:47:38Z

@nazywamsiepawel I am having same issue, Mojave 10.14, installing Julia via anaconda and trying to use jupyter. However, I was able to to get Julia working with juypter notebooks by avoiding Anaconda altogether. Using homebrew to install Julia, then running

using IJulia 
notebook()

worked for me. However I this is only the notebooks and I still want to be able to use JuypterLab

edit: fixed it by adding ENV["JUPYTER"]="jupyter"

liushuya7 · 2018-11-01T20:33:22Z

I'm having the exact same Issue when I tried to use IJulia via Anaconda. But problem solved when I switched to JuliaPro.

zlewko · 2018-11-04T14:48:05Z

same issue on ubuntu 18.04 when julia is installed via anaconda.

corrected with:
ln -s /usr/lib/llvm-6.0/lib/libLLVM-6.0.0.so /usr/lib/libLLVM.so

mgei · 2018-11-11T08:24:29Z

Same issue for me on Ubuntu 16.04, conda 4.5.11, Julia 1.0.1

GabrielEdogawa · 2018-11-14T18:34:16Z

same issue on ubuntu 18.04 when julia is installed via anaconda.

corrected with:
ln -s /usr/lib/llvm-6.0/lib/libLLVM-6.0.0.so /usr/lib/libLLVM.so

Yeah but I guess the solution differs in Mac. Can somebody show me where I can find libLLVM-6.0.0 in Mac system? I performed the same installation steps of the same version of Julia in a same Mac system with @nazywamsiepawel and I even do not know where to find that library.

versipellis · 2018-11-19T20:47:55Z

Confirming the same issue on Ubuntu 18.10, Julia 1.0.2, conda 4.5.11.

Also resolved with linking:
ln -s /usr/lib/llvm-5.0/lib/libLLVM-5.0.0.so /usr/lib/libLLVM.so

mbudisic · 2019-01-02T22:09:46Z

Confirming the same issue on Ubuntu 18.10, Julia 1.0.3, conda 4.5.12.

Fixed by softlinking as above.

yuvilio · 2019-01-06T18:49:34Z

Same here, ln -s fixed. Obviously the llvm's library path may slightly differ on different linux distros (and which package one uses to provide it) or other operatiing systems. For my Ubuntu 18.10 setup, it happened to be provided by a few packages including libjulia1.

Similarly fixed it with tracking the file down and making the libLLVM available in the more generic library path:

$ dpkg -S libLLVM.so 
llvm-6.0-dev: /usr/lib/llvm-6.0/lib/libLLVM.so
libjulia1: /usr/lib/x86_64-linux-gnu/julia/libLLVM.so
$ sudo ln -s /usr/lib/x86_64-linux-gnu/julia/libLLVM.so /usr/lib/libLLVM.so
$

The install requiring it, (Pkg.add("IJulia") in my case) worked smoothly after.

krinsman · 2019-01-17T03:51:50Z

Maybe this issue should be merge with (or vice versa) JuliaPackaging/BinaryProvider.jl#130 ?

It also seems to be discussed here: conda-forge/julia-feedstock#60

krinsman · 2019-01-17T05:06:25Z

Since this is an issue with the conda-forge julia package, the solution might be found in the current build script for that package, found here:

https://github.com/conda-forge/julia-feedstock/blob/master/recipe/build.sh

In particular, note that the package does not install the conda-forge llvm package for Julia to use by default, and that the following flag is used in the make: USE_SYSTEM_LLVM=0.

j-fu · 2019-04-04T14:58:38Z

Same issue on OpenSUSE 15 with julia 1.0.3 from the science repo, here we need ln -s /usr/lib64/libLLVM.so.5 /usr/lib64/libLLVM.so.
An alternative without root access is to link to a user accessible directory on LD_LIBRARY_PATH:

$ mkdir $HOME/lib64
$ ln -s /usr/lib64/libLLVM.so.5 $HOME/lib64/libLLVM.so
$ export LD_LIBRARY_PATH=$HOME/lib64/.$LD_LIBRARY_PATH

(I had some error trying this out for the inital version of this post)

j-fu · 2019-04-05T09:08:02Z

Same issue on OpenSUSE 15 with julia 1.0.3 from the science repo, here we need ln -s /usr/lib64/libLLVM.so.5 /usr/lib64/libLLVM.so.
An alternative without root access is to link to a user accessible directory on LD_LIBRARY_PATH:
$ mkdir $HOME/lib64
$ ln -s /usr/lib64/libLLVM.so.5 $HOME/lib64/libLLVM.so
$ export LD_LIBRARY_PATH=$HOME/lib64/.$LD_LIBRARY_PATH

Update (thanks to our sysadmin): OpenSuse 15 has a package llvm-devel which creates the link.
So this might be an issue of package dependencies to be addressed in the distro.

nalimilan · 2019-04-05T12:00:57Z

Can you file an issue against the OpenSUSE repo (and post the link here)?

j-fu · 2019-04-05T14:05:34Z

Same issue on OpenSUSE 15 with julia 1.0.3 from the science repo, here we need ln -s /usr/lib64/libLLVM.so.5 /usr/lib64/libLLVM.so.
An alternative without root access is to link to a user accessible directory on LD_LIBRARY_PATH:
$ mkdir $HOME/lib64
$ ln -s /usr/lib64/libLLVM.so.5 $HOME/lib64/libLLVM.so
$ export LD_LIBRARY_PATH=$HOME/lib64/.$LD_LIBRARY_PATH
Update (thanks to our sysadmin): OpenSuse 15 has a package llvm-devel which creates the link.
So this might be an issue of package dependencies to be addressed in the distro.
Update: Similar discussion is already running on https://bugzilla.opensuse.org/show_bug.cgi?id=1114692 .
I put in my 2cts in there and gave the link to the discussion here.

nalimilan · 2019-04-05T15:27:37Z

Thanks. Actually it looks like the problem is just that OpenSUSE should use USE_LLVM_SHLIB=1 instead of USE_LLVM_SHLIB=0 in the juliabuildopts file.

j-fu · 2019-10-07T13:25:36Z

Thanks for the hint. Over at OpenSuse they tried it and it worked: https://bugzilla.opensuse.org/show_bug.cgi?id=1114692#c7
On Tumbleweed I was able to check this - it is there now.

ViralBShah · 2020-12-17T14:45:48Z

Let's reopen if still an issue.

eahenle · 2022-09-22T21:50:37Z

Currently running into this issue when running the following CI workflow on GHA:

runs-on: windows-latest

steps:
      - name: checkout commit
        uses: actions/checkout@master

      - name: set up Julia
        uses: julia-actions/setup-julia@latest
        with:
          version: '1.8.1'
      
      - name: build package
        uses: julia-actions/julia-buildpkg@latest

WT215 · 2022-11-22T16:43:19Z

Currently running into this issue when running the following CI workflow on GHA:

runs-on: windows-latest

steps:
      - name: checkout commit
        uses: actions/checkout@master

      - name: set up Julia
        uses: julia-actions/setup-julia@latest
        with:
          version: '1.8.1'
      
      - name: build package
        uses: julia-actions/julia-buildpkg@latest

can you explained more on how to implement this please? Many thanks!

eahenle · 2022-11-22T17:49:32Z

@WT215 Sounds like you're asking generally about implementing CI on GitHub Actions? If so, let's chat on Gitter instead of cluttering this issue 😉

gustaphe · 2023-01-09T13:46:43Z

Currently running into this issue when running the following CI workflow on GHA

Did you end up solving this? I'm having the same problem.

eahenle · 2023-01-09T17:01:07Z

@gustaphe No ☹️

I have found the upstream issue, though: JuliaPackaging/BinaryProvider.jl#211
In my case, one of my package's dependencies uses BinaryProvider, which is deprecated.

msanchezr99 · 2023-09-12T04:47:52Z

Having this issue in Windows 10. I try to run "using Plots" and it shows FFMPEG not installed properly. It says I must run "build FFMPEG" but when I do it shows load error saying unable to open libLLVM. Don't know what to do!

droodman · 2024-03-31T19:47:27Z

I'm exactly same issue as described by @msanchezr99, except in Windows 11 Pro 23H2. It's preventing me from using Plots. Julia version 1.10.2.

Update: at least for me, this fix works. Find the llvm library with Base.libllvm_path() and then create a copy of it in the same folder called libLLVM.dll. No idea what the underlying issue is.

gustaphe · 2024-04-08T15:41:31Z

@droodman broken link.

StefanKarpinski assigned nalimilan Oct 18, 2018

Irratzo mentioned this issue Dec 24, 2018

Fails to find libLLVM on anaconda JuliaPackaging/BinaryProvider.jl#130

Open

nalimilan mentioned this issue Jan 16, 2019

Build fails with custom directories #27922

Open

krinsman mentioned this issue Jan 17, 2019

Julia error when using IJulia JuliaLang/IJulia.jl#717

Closed

jhardenberg mentioned this issue Jan 21, 2019

initial version of Julia support ESMValGroup/ESMValTool#654

Merged

CHNPAT005 mentioned this issue Jan 5, 2020

Build on MacOS Catalina ludvigak/FINUFFT.jl#12

Closed

ViralBShah closed this as completed Dec 17, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Pkg.build fails with LoadError: Unable to open libLLVM! #29720

Pkg.build fails with LoadError: Unable to open libLLVM! #29720

markleary commented Oct 18, 2018

nalimilan commented Oct 18, 2018

egnha commented Oct 25, 2018

moppymopperson commented Oct 25, 2018

nalimilan commented Oct 26, 2018

cdluminate commented Oct 27, 2018

cdluminate commented Oct 27, 2018

nazywamsiepawel commented Oct 29, 2018 •

edited

Loading

MaxBalashov commented Oct 29, 2018

quentinlouis commented Nov 1, 2018 •

edited

Loading

rnevils commented Nov 1, 2018 •

edited

Loading

liushuya7 commented Nov 1, 2018 •

edited

Loading

zlewko commented Nov 4, 2018

mgei commented Nov 11, 2018

GabrielEdogawa commented Nov 14, 2018

versipellis commented Nov 19, 2018 •

edited

Loading

mbudisic commented Jan 2, 2019

yuvilio commented Jan 6, 2019

krinsman commented Jan 17, 2019 •

edited

Loading

krinsman commented Jan 17, 2019 •

edited

Loading

j-fu commented Apr 4, 2019 •

edited

Loading

j-fu commented Apr 5, 2019

nalimilan commented Apr 5, 2019

j-fu commented Apr 5, 2019

nalimilan commented Apr 5, 2019

j-fu commented Oct 7, 2019

ViralBShah commented Dec 17, 2020

eahenle commented Sep 22, 2022

WT215 commented Nov 22, 2022

eahenle commented Nov 22, 2022

gustaphe commented Jan 9, 2023

eahenle commented Jan 9, 2023

msanchezr99 commented Sep 12, 2023

droodman commented Mar 31, 2024 •

edited

Loading

gustaphe commented Apr 8, 2024

Pkg.build fails with LoadError: Unable to open libLLVM! #29720

Pkg.build fails with LoadError: Unable to open libLLVM! #29720

Comments

markleary commented Oct 18, 2018

nalimilan commented Oct 18, 2018

egnha commented Oct 25, 2018

moppymopperson commented Oct 25, 2018

nalimilan commented Oct 26, 2018

cdluminate commented Oct 27, 2018

cdluminate commented Oct 27, 2018

nazywamsiepawel commented Oct 29, 2018 • edited Loading

MaxBalashov commented Oct 29, 2018

quentinlouis commented Nov 1, 2018 • edited Loading

rnevils commented Nov 1, 2018 • edited Loading

liushuya7 commented Nov 1, 2018 • edited Loading

zlewko commented Nov 4, 2018

mgei commented Nov 11, 2018

GabrielEdogawa commented Nov 14, 2018

versipellis commented Nov 19, 2018 • edited Loading

mbudisic commented Jan 2, 2019

yuvilio commented Jan 6, 2019

krinsman commented Jan 17, 2019 • edited Loading

krinsman commented Jan 17, 2019 • edited Loading

j-fu commented Apr 4, 2019 • edited Loading

j-fu commented Apr 5, 2019

nalimilan commented Apr 5, 2019

j-fu commented Apr 5, 2019

nalimilan commented Apr 5, 2019

j-fu commented Oct 7, 2019

ViralBShah commented Dec 17, 2020

eahenle commented Sep 22, 2022

WT215 commented Nov 22, 2022

eahenle commented Nov 22, 2022

gustaphe commented Jan 9, 2023

eahenle commented Jan 9, 2023

msanchezr99 commented Sep 12, 2023

droodman commented Mar 31, 2024 • edited Loading

gustaphe commented Apr 8, 2024

nazywamsiepawel commented Oct 29, 2018 •

edited

Loading

quentinlouis commented Nov 1, 2018 •

edited

Loading

rnevils commented Nov 1, 2018 •

edited

Loading

liushuya7 commented Nov 1, 2018 •

edited

Loading

versipellis commented Nov 19, 2018 •

edited

Loading

krinsman commented Jan 17, 2019 •

edited

Loading

krinsman commented Jan 17, 2019 •

edited

Loading

j-fu commented Apr 4, 2019 •

edited

Loading

droodman commented Mar 31, 2024 •

edited

Loading