Build error with 1.0.3 on AARCH64 #54

recri · 2019-01-06T12:05:45Z

Building Arpack ──────────→ `~/.julia/packages/Arpack/UiiMc/deps/build.log`
┌ Error: Error building `Arpack`: 
│ [ Info: Downloading https://github.com/JuliaLinearAlgebra/ArpackBuilder/releases/download/v3.5.0-3/Arpack.v3.5.0-3.aarch64-linux-gnu-gcc7.tar.gz to /home/rogercritchlow/.julia/packages/Arpack/UiiMc/deps/usr/downloads/Arpack.v3.5.0-3.aarch64-linux-gnu-gcc7.tar.gz...
│ ERROR: LoadError: LibraryProduct(nothing, ["libarpack"], :libarpack, "Prefix(/home/rogercritchlow/.julia/packages/Arpack/UiiMc/deps/usr)") is not satisfied, cannot generate deps.jl!
│ Stacktrace:
│  [1] error(::String) at ./error.jl:33
│  [2] #write_deps_file#152(::Bool, ::Function, ::String, ::Array{LibraryProduct,1}) at /home/rogercritchlow/.julia/packages/BinaryProvider/4F5Hq/src/Products.jl:414
│  [3] (::getfield(BinaryProvider, Symbol("#kw##write_deps_file")))(::NamedTuple{(:verbose,),Tuple{Bool}}, ::typeof(write_deps_file), ::String, ::Array{LibraryProduct,1}) at ./none:0
│  [4] top-level scope at none:0
│  [5] include at ./boot.jl:317 [inlined]
│  [6] include_relative(::Module, ::String) at ./loading.jl:1044
│  [7] include(::Module, ::String) at ./sysimg.jl:29
│  [8] include(::String) at ./client.jl:392
│  [9] top-level scope at none:0
│ in expression starting at /home/rogercritchlow/.julia/packages/Arpack/UiiMc/deps/build.jl:74

as a result of Pkg.add("Gadfly") running in a Linux container on an armv8 chromebook. julia installed from the binary build for 1.0.3 on aarch64, running in the Crostini container on a Samsung Chromebook Plus.

julia> versioninfo()
Julia Version 1.0.3
Commit 099e826241 (2018-12-18 01:34 UTC)
Platform Info:
  OS: Linux (aarch64-unknown-linux-gnu)
  CPU: unknown
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, cortex-a53)

ArpackBuilder builds versions of libarpack as if USE_BLAS64=1 had been specified, but there are archs that specify USE_BLAS64=0 in julia/Make.inc. The above error is thrown when Arpack dynamically loads its libarpack.so and cannot resolve the symbols created by USE_BLAS64=1 conventions. USE_BLAS64=1 specifies use of 64 bit integers when compiling libopenblas, renaming global symbols and the library binary itself with a _64 suffix.

A workaround is to trigger the build error, install the libarpack2 package from system repos, and copy the libarpack.so.2.0.0 binary from /usr/lib into .julia/packages/Arpack/.../deps/usr/lib.

This could be fixed by building both versions, USE_BLAS64={0,1}, of libarpack in ArpackBuilder, and deciding which to keep depending on whether this error gets thrown during the Arpack build. That might also work for the other open Arpack issues involving this error, too.

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

andreasnoack · 2019-01-06T12:17:31Z

Please provide the error message, all output from versioninfo and tell us how you installed Julia.

recri · 2019-01-06T12:50:02Z

Moved this comment into the description, where it was supposed to be.

andreasnoack · 2019-01-07T08:42:33Z

julia installed from the binary build for 1.0.3 on aarch64

Does that mean that you've downloaded it from https://julialang.org/downloads/?

Could you please try dlopen([path to BinaryProvider provided libarpack]) and post the output here?

recri · 2019-01-07T13:51:45Z

Downloaded from https://julialang-s3.julialang.org/bin/linux/aarch64/1.0/julia-1.0.3-linux-aarch64.tar.gz.

I've since compiled 1.1.0-rc1 from tarball with dependencies and applied exactly the same fix to it.

julia> dlopen("/usr/lib/libarpack.so.2.0.0")
Ptr{Nothing} @0x0000005ef2cf98f0

If that isn't what you were looking for, or if you need the output from 1.0.3, I can get it this afternoon.

andreasnoack · 2019-01-07T14:02:55Z

@staticfloat Any ideas?

ericst · 2019-01-07T19:47:02Z

Hello,

Not sure if this helps but I have the same problem on OpenSuSE Tumbleweed(x86_64 not aarch64). I installed Julia from the package manager.

Here is the output when I try to add Arpack:

(v1.0) pkg> add Arpack
 Resolving package versions...
 Installed Arpack ─ v0.3.0
  Updating `~/.julia/environments/v1.0/Project.toml`
  [7d9fca2a] + Arpack v0.3.0
  Updating `~/.julia/environments/v1.0/Manifest.toml`
  [7d9fca2a] + Arpack v0.3.0
  Building Arpack → `~/.julia/packages/Arpack/UiiMc/deps/build.log`
┌ Error: Error building `Arpack`: 
│ [ Info: Downloading https://github.com/JuliaLinearAlgebra/ArpackBuilder/releases/download/v3.5.0-3/Arpack.v3.5.0-3.x86_64-linux-gnu-gcc8.tar.gz to /home/ericst/.julia/packages/Arpack/UiiMc/deps/usr/downloads/Arpack.v3.5.0-3.x86_64-linux-gnu-gcc8.tar.gz...
│ ERROR: LoadError: LibraryProduct(nothing, ["libarpack"], :libarpack, "Prefix(/home/ericst/.julia/packages/Arpack/UiiMc/deps/usr)") is not satisfied, cannot generate deps.jl!
│ Stacktrace:
│  [1] error(::String) at ./error.jl:33
│  [2] #write_deps_file#152(::Bool, ::Function, ::String, ::Array{LibraryProduct,1}) at /home/ericst/.julia/packages/BinaryProvider/4F5Hq/src/Products.jl:414
│  [3] (::getfield(BinaryProvider, Symbol("#kw##write_deps_file")))(::NamedTuple{(:verbose,),Tuple{Bool}}, ::typeof(write_deps_file), ::String, ::Array{LibraryProduct,1}) at ./none:0
│  [4] top-level scope at none:0
│  [5] include at ./boot.jl:317 [inlined]
│  [6] include_relative(::Module, ::String) at ./loading.jl:1044
│  [7] include(::Module, ::String) at ./sysimg.jl:29
│  [8] include(::String) at ./client.jl:392
│  [9] top-level scope at none:0
│ in expression starting at /home/ericst/.julia/packages/Arpack/UiiMc/deps/build.jl:74
[20:40:53] ######################################################################## 100.0% 
└ @ Pkg.Operations /home/abuild/rpmbuild/BUILD/julia-1.0.3/usr/share/julia/stdlib/v1.0/Pkg/src/Operations.jl:1097

And here is the output of versioninfo():

julia> versioninfo()
Julia Version 1.0.3
Commit 04330c0378 (2018-12-16 21:23 UTC)
Platform Info:
  OS: Linux (x86_64-suse-linux)
  CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, broadwell)

ericst · 2019-01-07T20:04:32Z

I just tried again with the generic binaries 1.0.3 on julialang.org and it worked without a problem. So it looks like more of a problem of the opensuse package than of Arpack itself.

andreasnoack · 2019-01-07T20:15:17Z

So it looks like more of a problem of the opensuse package than of Arpack itself.

It is probably a little more complicated. See #5 for some context.

staticfloat · 2019-01-07T23:29:21Z

@ericst please open a new issue; your issue is independent, likely related to #5, but I'm not certain. When you open a new issue, please provide as much context as you can.

Regarding this issue, it looks like there's a bug in our Arpack.jl binaries; we told libarpack.so to link against libopenblas64_.so, but the official julia binaries ship libopenblas.so. @andreasnoack is this a bug in Julia (should we be naming the openblas library with a 64_ suffix on AArch64) or is this a bug in ArpackBuilder (should we be linking against an libopenblas.so?)

recri · 2019-01-08T01:09:09Z

Compiling libopenblas with USE_BLAS64=1 on AARCH64 throws SEGV in blas testing.

At least the 32bit intel and armv7 architectures are shipping libopenblas.so, too.

ericst · 2019-01-08T21:59:58Z

@staticfloat done, it is #55. I am just starting out with julia, as soon as I know more I will look more into it.

robsmith11 · 2019-02-11T11:01:06Z

I have the same error as in the original post with the official Julia aarch64 binary using chrooted Arch Arm Linux on an Android tablet:

julia> versioninfo(verbose=true)
Julia Version 1.0.3
Commit 099e826241 (2018-12-18 01:34 UTC)
Platform Info:
  OS: Linux (aarch64-unknown-linux-gnu)
  uname: Linux 3.18.71-gbf3ecfa #1 SMP PREEMPT Thu Jul 19 15:46:30 +03 2018 aarch64 unknown
  CPU: unknown:
              speed         user         nice          sys         idle          irq
       #1   307 MHz      31735 s        643 s      29334 s     540736 s      11893 s
       #2   307 MHz      13844 s        607 s      22214 s     579830 s       2362 s
       #3  1920 MHz      53484 s       2150 s      63488 s     485885 s       4203 s
       #4  1920 MHz      45239 s       1939 s      41030 s     523433 s       2582 s

  Memory: 3.3130035400390625 GB (302.390625 MB free)
  Uptime: 16850.0 sec
  Load Avg:  5.70458984375  5.8095703125  5.83984375
  WORD_SIZE: 64
  LIBM: libopenlibm
  LLVM: libLLVM-6.0.0 (ORCJIT, kryo)
Environment:
  MOZ_PLUGIN_PATH = /usr/lib/mozilla/plugins
  HOME = /home/me
  TERM = screen-256color
  PATH = /home/me/.cargo/bin:/home/me/.cargo/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl

EDIT:
@staticfloat I tried copying libopenblas.so to libopenblas64_.so, but still get the same build failure. Would you have expected that to fix it?

EDIT2:
I missed the last part from the orignal post. Copying over libarpack.so from Arch Arm Linux is working for me with Julia Nightly for Aarch64.

AbduElturki · 2019-08-02T14:23:12Z

Had the same issue on Nvidia Jetson TX2 (Aarch64), installing libarpack2 and copying libarpack.so.2.0.0 has fixed the issue with Julia LTS.

oschulz · 2019-08-12T16:17:18Z

Just ran into this myself, on an Nvidia Jetson Nano. It's an awesome demo system for Julia (cheap and CUDA works out of the box), would be great if Arpack could support Aarch64 without the workaround.

andreasnoack · 2019-08-13T07:49:20Z

@oschulz Are you using the official binaries?

oschulz · 2019-08-13T07:57:05Z

@oschulz Are you using the official binaries?

Yes, I tried with the official Julia v1.2-rc2 and v1.3-alpha binaries. Then I just ran add Distributions on the Jetson Nano, which pulled in Arpack.

andreasnoack · 2019-08-13T08:12:46Z

Yes, I tried with the official Julia v1.2-rc2 and v1.3-alpha binaries. Then I just ran add Distributions on the Jetson Nano, which pulled in Arpack.

@staticfloat Shouldn't have just worked?

staticfloat · 2019-08-13T08:36:09Z

Yes, I think so, although I don't have a Jetson Nano to test with locally, so it's hard to say what could be going wrong.

oschulz · 2019-08-13T13:45:45Z

Ok, maybe I should test this again then, to make sure it wasn't a fluke. I'm travelling this week, will give it another try next week.

andreasnoack · 2020-07-31T11:11:42Z

@oschulz Is this still an issue?

oschulz · 2020-07-31T11:33:31Z

Ah, sorry for never getting back to your to this! Just tested is on a Jetson Xavier NX, all seems fine! I think this can be closed.

andreasnoack mentioned this issue Sep 11, 2019

Does not build on Aarch64 Jetson Nano. #73

Closed

andreasnoack mentioned this issue Sep 23, 2019

Fail to build on Arch64 #74

Closed

dehann mentioned this issue Dec 4, 2019

travis arm64 allow failures #80

Merged

andreasnoack closed this as completed Jul 31, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Build error with 1.0.3 on AARCH64 #54

Build error with 1.0.3 on AARCH64 #54

recri commented Jan 6, 2019 •

edited

Loading

andreasnoack commented Jan 6, 2019

recri commented Jan 6, 2019 •

edited

Loading

andreasnoack commented Jan 7, 2019

recri commented Jan 7, 2019

andreasnoack commented Jan 7, 2019

ericst commented Jan 7, 2019

ericst commented Jan 7, 2019

andreasnoack commented Jan 7, 2019

staticfloat commented Jan 7, 2019

recri commented Jan 8, 2019

ericst commented Jan 8, 2019

robsmith11 commented Feb 11, 2019 •

edited

Loading

AbduElturki commented Aug 2, 2019

oschulz commented Aug 12, 2019

andreasnoack commented Aug 13, 2019

oschulz commented Aug 13, 2019

andreasnoack commented Aug 13, 2019

staticfloat commented Aug 13, 2019

oschulz commented Aug 13, 2019

andreasnoack commented Jul 31, 2020

oschulz commented Jul 31, 2020

Build error with 1.0.3 on AARCH64 #54

Build error with 1.0.3 on AARCH64 #54

Comments

recri commented Jan 6, 2019 • edited Loading

andreasnoack commented Jan 6, 2019

recri commented Jan 6, 2019 • edited Loading

andreasnoack commented Jan 7, 2019

recri commented Jan 7, 2019

andreasnoack commented Jan 7, 2019

ericst commented Jan 7, 2019

ericst commented Jan 7, 2019

andreasnoack commented Jan 7, 2019

staticfloat commented Jan 7, 2019

recri commented Jan 8, 2019

ericst commented Jan 8, 2019

robsmith11 commented Feb 11, 2019 • edited Loading

AbduElturki commented Aug 2, 2019

oschulz commented Aug 12, 2019

andreasnoack commented Aug 13, 2019

oschulz commented Aug 13, 2019

andreasnoack commented Aug 13, 2019

staticfloat commented Aug 13, 2019

oschulz commented Aug 13, 2019

andreasnoack commented Jul 31, 2020

oschulz commented Jul 31, 2020

recri commented Jan 6, 2019 •

edited

Loading

recri commented Jan 6, 2019 •

edited

Loading

robsmith11 commented Feb 11, 2019 •

edited

Loading