User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/112.0 Build Identifier: Hello, I have a fresh install of F38 on a 64-bit x86 Intel machine, on which I’ve installed Julia via: sudo dnf install julia This fetched the following packages: Installing: julia x86_64 1.9.0-0.beta4.fc38 Installing dependencies: dSFMT x86_64 2.2.3-20.fc38 http-parser x86_64 2.9.4-8.fc38 julia-common noarch 1.9.0-0.beta4.fc38 libgit2 x86_64 1.6.3-1.fc38 openlibm x86_64 0.7.5-5.fc38 p7zip-plugins x86_64 16.02-25.fc38 utf8proc x86_64 2.7.0-4.fc38 However, when I try to start the Julia REPL, I’m presented with the following error that an OpenBLAS (libopenblas64_.so) library can’t be found: [user@fedora ~]$ julia fatal: error thrown and no exception handler available. InitError(mod=:OpenBLAS_jll, error=ErrorException("could not load library "libopenblas64_.so" libopenblas64_.so: cannot open shared object file: No such file or directory")) ijl_errorf at /usr/bin/../lib64/julia/libjulia-internal.so.1 (unknown line) ijl_load_dynamic_library at /usr/bin/../lib64/julia/libjulia-internal.so.1 (unknown line) unknown function (ip: 0x7f69f4d9ce78) unknown function (ip: 0x7f69f4740602) unknown function (ip: 0x7f69f4740888) unknown function (ip: 0x7f6a1647f9ff) unknown function (ip: 0x7f6a164692eb) jl_repl_entrypoint at /usr/bin/../lib64/julia/libjulia-internal.so.1 (unknown line) main at julia (unknown line) __libc_start_call_main at /usr/bin/../lib64/libc.so.6 (unknown line) __libc_start_main at /usr/bin/../lib64/libc.so.6 (unknown line) _start at julia (unknown line) The same error also occurs when running a basic Julia program: julia hello_world.jl I attempted to fix this by identifying a package which would contain this library via: dnf provides 'libopenblas*' and installed the matching package openblas-serial64_, but the error persists. From reading online, I understand that Julia can be distributed with it’s own internal copy of OpenBLAS, but I’m not sure how I would test if that is properly configured in this case. If anyone has thoughts on how I might investigate further, I would be very grateful. It appears this is likely an issue with the way Julia was compiled and packaged, based on these posts across the web reporting similar package issues: https://bugs.archlinux.org/task/70164 https://github.com/SciML/DifferentialEquations.jl/issues/737 https://github.com/SciML/DifferentialEquations.jl/issues/738 https://www.reddit.com/r/Julia/comments/me8hes/comment/gsgf8jd/ Reproducible: Always Steps to Reproduce: 1. Install Julia: sudo dnf install julia 2. Attempt to start Julia REPL: julia OR 2. Attempt to run a basic Julia script: julia hello_world.jl Actual Results: Julia fails to start, as a necessary OpenBLAS library wasn't found. Expected Results: Julia REPL should start. Some auxiliary options of the Julia binary still work, like 'julia --help' for example.
Good catch. This is because OpenBLAS is no longer detected automatically as a dependency. You can install manually openblas-threads64_ if you don't want to wait for the fix.
(In reply to Milan Bouchet-Valat from comment #1) > Good catch. This is because OpenBLAS is no longer detected automatically as > a dependency. You can install manually openblas-threads64_ if you don't want > to wait for the fix. Thank you for looking into this, I really appreciate your help. I'm curious what the '_' suffix on the package name signifies; the description indicates it is a 'symbol name suffix'? Your suggested temporary fix works for me. Julia starts and one can import standard libraries and plot functions, etc. When loading the Julia REPL, however, I did notice a non-blocking error: ┌ Error: Error during initialization of module CHOLMOD │ exception = │ could not load library "libcholmod" │ libcholmod.so: cannot open shared object file: No such file or directory └ @ SparseArrays.CHOLMOD /usr/share/julia/stdlib/v1.9/SparseArrays/src/solvers/cholmod.jl:242 Could this potentially indicate another dependency that should be marked for install alongside the main Julia package?
FEDORA-2023-17a5e4ca79 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-17a5e4ca79
(In reply to Kennedy Caisley from comment #2) > (In reply to Milan Bouchet-Valat from comment #1) > > Good catch. This is because OpenBLAS is no longer detected automatically as > > a dependency. You can install manually openblas-threads64_ if you don't want > > to wait for the fix. > > Thank you for looking into this, I really appreciate your help. I'm curious > what the '_' suffix on the package name signifies; the description indicates > it is a 'symbol name suffix'? Yes, Julia uses an OpenBLAS with symbol names suffixed with _64 to avoid conflicts if one links to a library which uses a standard (LP64 rather than ILP64) OpenBLAS. > Your suggested temporary fix works for me. Julia starts and one can import > standard libraries and plot functions, etc. > > When loading the Julia REPL, however, I did notice a non-blocking error: > > ┌ Error: Error during initialization of module CHOLMOD > │ exception = > │ could not load library "libcholmod" > │ libcholmod.so: cannot open shared object file: No such file or directory > └ @ SparseArrays.CHOLMOD > /usr/share/julia/stdlib/v1.9/SparseArrays/src/solvers/cholmod.jl:242 > > Could this potentially indicate another dependency that should be marked for > install alongside the main Julia package? Damn. Of course the same change needs to be applied to SuiteSparse. I'll push a fix. It's really unfortunate that tests are run during the build rather than after installing the package on a clean system.
FEDORA-2023-17a5e4ca79 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-17a5e4ca79` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-17a5e4ca79 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-b17d483574 has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-b17d483574
FEDORA-2023-b17d483574 has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-b17d483574` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-b17d483574 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-99fd4698da has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-99fd4698da
FEDORA-2023-99fd4698da has been pushed to the Fedora 38 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-99fd4698da` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-99fd4698da See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2023-99fd4698da has been pushed to the Fedora 38 stable repository. If problem still persists, please make note of it in this bug report.