Arpack build fails on JuliaPro 1.0.1.1 under Windows


#1

when trying to do:

using Arpack

I get

[ Info: Precompiling Arpack [7d9fca2a-8960-54d3-9f78-7d1dccf2cb97]
ERROR: LoadError: No deps.jl file could be found. Please try running Pkg.build(“Arpack”). …

so I try

Pkg.build(“Arpack”)

and I get

Building Arpack → C:\Users\alotpie89508\AppData\Local\JuliaPro1011\pkgs-1.0.1.1\packages\Arpack\U iiMc\deps\build.log
┌ Error: Error building Arpack :
│ ERROR: LoadError: UndefVarError: CompilerABI not defined
│ Stacktrace:
│ [1] top-level scope at none:0
│ [2] include at .\boot.jl:317 [inlined]
│ [3] include_relative(::Module, ::String) at .\loading.jl:1041
│ [4] include(::Module, ::String) at .\sysimg.jl:29
│ [5] include(::String) at .\client.jl:388
│ [6] top-level scope at none:0
│ in expression starting at C:\Users\alotpie89508\AppData\Local\JuliaPro1011\pkgs-1.0.1.1\packages\A
rpack\UiiMc\deps\build.jl:14
└ @ Pkg.Operations C:\Users\julia\AppData\Local\Julia-1.0.1\share\julia\stdlib\v1.0\Pkg\src\Operatio
ns.jl:1101

Any ideas?
Thanks in advance,
Pier


#2

I have two thoughts. I see in the path: “\Arpack\U iiMc” and then later in the error message, “\A
rpack\UiiMc” without space.

Paths/directory/file names with spaces weren’t even supported on Windows in the past and while it is now, I’m not sure always well supported (if that’s the case, you can maybe get rid of it as a workaround, but this may be an issue to report for Arpack and/or its dependency BuildProvider, that possibly needs to handle such). Possibly neither on Unix/Linux (e.g. in bash) or at least you may need to be careful.

I’m not sure where this “U iiMc” comes from, it has no meaning to me (nor did I locate it in Arpack.jl or related source code).

I just see that the package itself has a two months old “fix for Julia 1.0” and has an ok build (for Linux, but is it for sure tested on Windows?): https://travis-ci.org/JuliaLinearAlgebra/Arpack.jl/jobs/442549381

It should work in Julia 1.0.1 also, and what works in Julia should work in the similar JuliaPro. You could try Julia 1.0.1 (or 1.0), but as I said I don’t think it should be needed as I think this may be the space and/or Windows issue.

Even with you using JuliaPro, you may want to report stuff in non-JuliaPro Discourse (at least uless you’re sure it’s JuliaPro-specific error). I see some other threads there (one on other on install error with MKL, and some threads elsewhere on the web):


#3

Thanks for the kind reply!
The “U iiMc” thing was just due to a problem with cut-and-past. It is actually ok.
To me, but I am no expert, the problem seems to be the CompilerABI thing… which package should define it?
Furthermore, I need Arpack because it is required by Distributions, which is the package I actually want to use.


#4

I can clearly see now that Arpack is targeting Windows (and at least Linux and FreeBSD too). I looked up the error message and found another package that also targets Windows and should work, and maybe the discussion (that’s now closed) helps:

Unlike the latter that REQUIRES BinaryProvider 0.5, Arpack only requires 0.3. I’m not sure if it should require later.

Are you sure you’re using the latest package also (I saw it got an upgrade 15 days ago, but it seemed to also support Windows before, maybe not as well, for as many old computer, do you have an old one?).


#5

0.4 had:

so I find it likely Arpack should require more than 0.3, maybe even 0.6. You could make a PR and/or test first for you locally. I rather not want to if I’m wrong and I can’t test on Windows. As 0.4 dropped support for Julia 0.6, then possibly it’s a consideration, just not for you.


#6

Have you modified anything related to which registry you are using? If not, could you try to run pkg> update.


#7

Have you tried building it with official julia binaries? I had a building error with Arpack on Julia from my OS’s repository.


#8

Apparently I messed up something with the registry. After a fresh re-install of JuliaPro 1.0.1.1 Arpack built without problems.
Sorry for causing unnecessary alarm and thanks for your replies.