Arch Linux User Repository

Pre-built binaries of this package can be found in the arch4edu repository.

EDIT: I was able to solve this issue by adding options=(!buildflags !makeflags) to the PKGBUILD. It seems some of the CFLAGS settings in /etc/makepkg.conf were conflicting with Julia's build flags.

I get the following error when trying to build this package (both when using an AUR helper and without):

/usr/include/c++/10.2.0/bits/stl_vector.h:1045: std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](std::vector<_Tp, _Alloc>::size_type) [with _Tp = unsigned char; _Alloc = std::allocator<unsigned char>; std::vector<_Tp, _Alloc>::reference = unsigned char&; std::vector<_Tp, _Alloc>::size_type = long unsigned int]: Assertion '__builtin_expect(__n < this->size(), true)' failed.

Got a similar bug to the first time (missing link to libimf.so). Fixed with: sudo ln -s '/opt/intel/oneapi/compiler/2021.2.0/linux/compiler/lib/intel64/libimf.so' '/usr/lib/julia'

I forgot to push intel-oneapi-compiler-shared too. You may need to rebuild it.

Sorry I forgot to push that package. It should be fixed now.

Hmm, trying to update gives me the bug: ar: intel-oneapi-dpcpp-debugger-eclipse-cfg-10.1.1-10.1.1-80_all.deb: No such file or directory

Oops, libimf.so is the intel libm ...

I'll add intel-oneapi-compiler-shared to depends.

Oops, I was trying to use the intel libm actually.

It seems that intel libm is missing now, then it fallback to openlibm.

I'm migrating the intel packages from ubuntu. And somehow I find libimf.so in intel-oneapi-compiler-shared-runtime.

It will be helpful if someone can tell me which package have the intel libm.

Got a bug where Julia didn't start up because the link to openlibm is missing. This is fixed by creating and placing a link to openlibm using the following:

sudo ln -s '/usr/lib/libopenlibm.so' '/usr/lib/julia'

@petronny thanks. When you update to 1.6.1, you may want to remove the dependency on llvm10 and llvm10-libs and replace these with llvm and llvm-libs (which will use the newest version). You may also want to check that every requirement is listed (namely, everything that has the USE_SYSTEM flag set to 1 is actually a requirement for this package) and that no unnecessary requirements have been added.

I just realized that maybe libimf.so is not that important since it's not even provdied in ubuntu.

So I tried removing libimf and everything still work.

I applied this change in 1.5.4 .

I'll take a look about 1.6.x in a few days.

I find that there is an apt repository of all oneapi packages for ubuntu.

If someone can find the package containing libimf.so in ubuntu then we can create a *-bin package to port it to arch.

But apt-file find libimf.so says there is no libimf.so in the entire repository.

@rgcv I've noticed that there is a new version.

But now I don't know what to do due to the changes in the intel packages.

@petronny @halfhorn I think one of these might contain the required file: https://github.com/intel/llvm https://github.com/oneapi-src/oneDPL https://github.com/oneapi-src/oneDAL

If not, one of the other packages here may have it: https://github.com/oneapi-src

Or this may help: https://github.com/oneapi-src/oneDAL/blob/master/INSTALL.md

I had already flagged it out of date when 1.5.4 released. In the meantime, a new minor release has been published: https://github.com/JuliaLang/julia/releases/tag/v1.6.0

I've been playing around with trying to package the OneAPI base toolkit but it is a major pain as it uses a custom sh installer.sh method of installation.

See here to download the installer from intel and the instructions for custom installs.

I can confirm that it contains the needed libimf.so.

$ find . -name libimf.so
/opt/intel/oneapi/compiler/2021.1.1/linux/compiler/lib/intel64_lin/libimf.so
/opt/intel/oneapi/compiler/2021.1.1/linux/compiler/lib/ia32_lin/libimf.so
/opt/intel/oneapi/intelpython/python3.7/envs/2021.1.1/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.7/pkgs/common_cmplr_lib_rt-2021.1.1-intel_189/lib/libimf.so
/opt/intel/oneapi/intelpython/python3.7/lib/libimf.so

@petronny I don't know which other packages on the AUR provide it. It looks like Intel's OneAPI Base Toolkit isn't on the AUR, which I find very surprising, but you can find the OneAPI Base Toolkit here: https://software.intel.com/content/www/us/en/develop/tools/oneapi/base-toolkit/download.html

This should provide the necessary file (let me know if it doesn't). If you're interested, you could add it to the AUR (I'm fairly new to Arch so not quite sure how to do that myself); it looks useful enough that it should probably be added. It should also be possible to find which library provides libimf.so so you don't have to install the whole OneAPI library, just the component providing it.

@Lime For now julia-mkl need libimf.so to build. AFAIK only intel-common-libs is providing it.

Please let me know if there is a better way to get libimf.so .

@petronny The following package, which is a make requirement for Julia-mkl, is currently marked as out-of-date and has been disowned: https://aur.archlinux.org/packages/intel-common-libs When I attempt to build it, I get an error message because the file "parallel_studio_xe_2020_update4_cluster_edition.tgz" fails sha256 sum validation. In the comments section, it was mentioned that Intel Parallel Studio XE is being replaced with oneAPI toolkits.

Pre-built binaries of this package can be found in the arch4edu repository.

intel-common-libs is no longer supported

@Lime Could you provide more details for this?

trying to build julia-mkl fails because of this.

I just build this package in a clean chroot. You may want to try the prebuilt binary.

intel-common-libs is no longer supported; trying to build julia-mkl fails because of this.

Hi, I am getting this error when compiling julia-mkl:

/tmp/yay/julia-mkl/src/julia-1.5.2/src/ccall.cpp:994:68:   required from here
/usr/include/llvm/ADT/STLExtras.h:185:52: error: expression cannot be used as a function
  185 |     return (*reinterpret_cast<Callable*>(callable))(
      |            ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^
  186 |         std::forward<Params>(params)...);
      |         ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
make[1]: *** [Makefile:166: codegen.o] Error 1
make[1]: Leaving directory '/tmp/yay/julia-mkl/src/julia-1.5.2/src'

AFAIK, the build prefix is embedded in /usr/lib/julia/sys.so. If I edit it with sed, /usr/bin/julia will raise segmentation fault. I don't know is there a proper way to edit this file now.

@xia0er There is already a bug report about the prefix, see https://bugs.archlinux.org/task/63255.

Abount openmp, should it be a dependency of julia-arpack?
I can pass most of the tests in the check() function with about 5 tests skipped.
So I think julia-mkl doesn't need openmp itself.

Should openmp be added to the package dependencies? I am getting an error:

julia: symbol lookup error: /opt/intel/mkl/lib/intel64/libmkl_intel_thread.so: undefined symbol: __kmpc_global_thread_num

when loading julia packages that depend on mkl, for example, Arpack, which is fixed by installing openmp.

@petronny, thanks for the response! As I understand it is mostly cosmetic, I can certainly wait for it to be resolved upstream.

@xia0er Actually this bug also happens in the official julia package.

julia> using Pkg

julia> Pkg.build("Arpack")
ERROR: The following package names could not be resolved:
 * Arpack (not found in project or manifest)
Please specify by known `name=uuid`.
Stacktrace:
 [1] ensure_resolved at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/Types.jl:981 [inlined]
 [2] #build#61(::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:375
 [3] build at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:357 [inlined]
 [4] #build#60 at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:355 [inlined]
 [5] build at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:355 [inlined]
 [6] #build#57 at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:352 [inlined]
 [7] build(::String) at /build/julia/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:352
 [8] top-level scope at none:0

You can find /build/julia/src/julia-1.1.1/ in the stacktrace which is the build path in chroot since it is build with extra-x86_64-build.

I provide a pre-built binary of this package which is also built with extra-x86_64-build in arch4edu. It will give the similar stacktrace like the official one. You can use it for now. I'll contact with the maintainer of julia and see what we can do about the build path.

Is there a way to fix the fact that where julia is being built is embedded in the installed files? For example, when I got permission denied error for a log file, the error message reports the Operations.jl is at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl (where julia-mkl is being built by yay), even though I started julia after installing julia-mkl and can verify that Operations.jl is at /usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl. Granted this is mostly cosmetic as far as I can see.

julia> Pkg.build("Arpack")
  Building Arpack → `/usr/share/julia/packages/Arpack/cu5By/deps/build.log`
ERROR: SystemError: opening file "/usr/share/julia/packages/Arpack/cu5By/deps/build.log": Permission denied
Stacktrace:
 [1] #open#310(::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::getfield(Pkg.Operations, Symbol("##52#57")){Bool,Cmd}, ::String, ::Vararg{Str
ing,N} where N) at ./iostream.jl:373
 [2] #53 at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:1080 [inlined]
 [3] #41 at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:898 [inlined]
 [4] withenv(::getfield(Pkg.Operations, Symbol("##41#46")){getfield(Pkg.Operations, Symbol("##53#58")){getfield(Pkg.Operations, Symbol("##51#56")){Bool,String,Cmd,String}},Pkg.Ty
pes.Context}, ::Pair{String,String}, ::Vararg{Pair{String,B} where B,N} where N) at ./env.jl:148
 [5] mktempdir at ./file.jl:579 [inlined]
 [6] #with_dependencies_loadable_at_toplevel#38(::Bool, ::Function, ::getfield(Pkg.Operations, Symbol("##53#58")){getfield(Pkg.Operations, Symbol("##51#56")){Bool,String,Cmd,Stri
ng}}, ::Pkg.Types.Context, ::Pkg.Types.PackageSpec) at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/Operations.jl:853
 [7] #build_versions at ./none:0 [inlined]
 [8] #build#61(::Bool, ::Base.Iterators.Pairs{Union{},Union{},Tuple{},NamedTuple{(),Tuple{}}}, ::Function, ::Pkg.Types.Context, ::Array{Pkg.Types.PackageSpec,1}) at /home/xia0er/
.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:382
 [9] build at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:357 [inlined]
 [10] #build#60 at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:355 [inlined]
 [11] build at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:355 [inlined]
 [12] #build#57 at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:352 [inlined]
 [13] build(::String) at /home/xia0er/.cache/yay/julia-mkl/src/julia-1.1.1/usr/share/julia/stdlib/v1.1/Pkg/src/API.jl:352
 [14] top-level scope at none:0

Hi, I just dropped julia-mkl-docs.
I think it's same with julia-docs. Please leave a comment if it's not. I will add it back.

maybe help https://gist.github.com/specter119/e7a86a202b0ecb77334cb5c437085e5e