gfortran error

[senna1128]

Hi,

Thanks for your excellent maintenance of the CUTEst package.

I'm trying to install CUTEst on Julia. It seems I can run Pkg.add("CUTEst") but it would report error when I then run using CUTEst. The error is InitError: IOError: could not spawn `bash -c 'type gfortran'`: no such file or directory (ENOENT). I have tried to install gcc to my computer, but it does not fix the issue.

I'm using Windows 11, Julia v1.9.1, and my gcc v10.3.0

Thanks for the help in advance.

[abelsiqueira]

Hi @senna1128, thanks for reporting the error.

We don't officially support Windows - installing CUTEst (Fortran) on it is not trivial, and making the result work with Julia adds another layer of complexity.

The gist of the issue that you mentioned seems to be that bash was not found. This comes from a run(`bash ...`) command, so probably the command is run from the Windows cmd.exe, which doesn't have the bash command.
If it had bash, then it would try to run type, which is another command it probably doesn't have.
And type gfortran would check that gfortran, the command, exists, which it probably won't.

In other words, there is no easy fix to support Windows, it would need someone with time availability and some CUTEst (Fortran) proficiency to look over the whole code and add conditionals to treat Windows differently.

It has been a while since anybody tried it, so maybe WSL can be used to have it working smoothly, but how Julia interacts with WSL, we don't know.

Let us know if you would like to spend some time trying to add Windows support. Otherwise, the solution is to use a Linux or OSX machine.

[NicolasL-S]

Hi @abelsiqueira and @senna1128,

I'm also trying to make CUTEst work on WSL. Up to now, I've used CUTEst.jl by juggling between a Ubuntu and a Windows machine. So I can already greatly appreciate the efforts put in maintaining CUTEst and I could go on as is. But if this gets resolved, I'd be a happy customer.

I've tried Julia on WSL and everything seems to work well. With my limited experience in Linux, I managed to install gfortran (not without trial and error) and add CUTEst.jl. The line success(`bash -c "type gfortran"`) returns true. However, I ended up here because using CUTEst errors at global libgfortran = [strip(read(`gfortran --print-file libgfortran.so`, String))]:

ERROR: InitError: IOError: could not spawn `gfortran --print-file libgfortran.so`: no such file or directory (ENOENT)
Stacktrace:
  [1] _spawn_primitive(file::String, cmd::Cmd, stdio::Vector{Union{RawFD, Base.Libc.WindowsRawSocket, IO}})
    @ Base .\process.jl:128
  [2] #760
    @ .\process.jl:139 [inlined]
  [3] setup_stdios(f::Base.var"#760#761"{Cmd}, stdios::Vector{Union{RawFD, Base.Libc.WindowsRawSocket, IO}})
    @ Base .\process.jl:223
  [4] _spawn
    @ .\process.jl:138 [inlined]
  [5] open(cmds::Cmd, stdio::Base.DevNull; write::Bool, read::Bool)
    @ Base .\process.jl:393
  [6] open
    @ .\process.jl:383 [inlined]
  [7] open(cmds::Cmd, mode::String, stdio::Base.DevNull)
    @ Base .\process.jl:364
  [8] read(cmd::Cmd)
    @ Base .\process.jl:447
  [9] read
    @ .\process.jl:458 [inlined]
 [10] __init__()
    @ CUTEst C:\Users\Nicolas\.julia\packages\CUTEst\FWOg3\src\CUTEst.jl:70
 [11] register_restored_modules(sv::Core.SimpleVector, pkg::Base.PkgId, path::String)
    @ Base .\loading.jl:1074
 [12] _include_from_serialized(pkg::Base.PkgId, path::String, ocachepath::String, depmods::Vector{Any})
    @ Base .\loading.jl:1020
 [13] _require_search_from_serialized(pkg::Base.PkgId, sourcepath::String, build_id::UInt128)
    @ Base .\loading.jl:1471
 [14] _require(pkg::Base.PkgId, env::String)
    @ Base .\loading.jl:1748
 [15] _require_prelocked(uuidkey::Base.PkgId, env::String)
    @ Base .\loading.jl:1625
 [16] macro expansion
    @ .\loading.jl:1613 [inlined]
 [17] macro expansion
    @ .\lock.jl:267 [inlined]
 [18] require(into::Module, mod::Symbol)
    @ Base .\loading.jl:1576
 [19] eval
    @ .\boot.jl:370 [inlined]
 [20] eval
    @ .\Base.jl:68 [inlined]
 [21] repleval(m::Module, code::Expr, #unused#::String)
    @ VSCodeServer c:\Users\Nicolas\.vscode\extensions\julialang.language-julia-1.47.2\scripts\packages\VSCodeServer\src\repl.jl:222
 [22] (::VSCodeServer.var"#107#109"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer c:\Users\Nicolas\.vscode\extensions\julialang.language-julia-1.47.2\scripts\packages\VSCodeServer\src\repl.jl:186
 [23] with_logstate(f::Function, logstate::Any)
    @ Base.CoreLogging .\logging.jl:514
 [24] with_logger
    @ .\logging.jl:626 [inlined]
 [25] (::VSCodeServer.var"#106#108"{Module, Expr, REPL.LineEditREPL, REPL.LineEdit.Prompt})()
    @ VSCodeServer c:\Users\Nicolas\.vscode\extensions\julialang.language-julia-1.47.2\scripts\packages\VSCodeServer\src\repl.jl:187
 [26] #invokelatest#2
    @ .\essentials.jl:816 [inlined]
 [27] invokelatest(::Any)
    @ Base .\essentials.jl:813
 [28] macro expansion
    @ c:\Users\Nicolas\.vscode\extensions\julialang.language-julia-1.47.2\scripts\packages\VSCodeServer\src\eval.jl:34 [inlined]
 [29] (::VSCodeServer.var"#61#62")()
    @ VSCodeServer .\task.jl:514
during initialization of module CUTEst

In case that helps, my versions are

Ubuntu 22.04.2 LTS
gfortran 11.3.0
Windows 11
Julia v1.9.0

[senna1128]

Hi @abelsiqueira , thanks for your reply. I tried but still could not fix the issue on Windows. Sometimes I can even run using CUTEst but functions in packages are still undefined. So I decided to use CUTEst on macOS, which just works fine. Sorry for the trouble.

@NicolasL-S I did not encounter this error. I'm not sure how to make CUTEst compatible with Windows. Even I can run using CUTEst, functions are still undefined in my case, which makes things too complex for me:)

[abelsiqueira]

Hi @NicolasL-S, thanks for looking into this. The error looks like either the gfortran command did not work or the libgfortran.so was not found. Can you try run(`gfortran --version`)?

@senna1128, nice to hear that. Good luck, and thanks for using CUTEst.

[NicolasL-S]

Hi @abelsiqueira and @senna1128

As @abelsiqueira suggested, I've tried run(`gfortran --version`) and Julia couldn't find it. But I verified and my installation of gfortran works fine. That's when it hit me, the problem is I'm running my Windows installation of Julia which has no clue I'm trying to call some Windows Subsystem for Linux (WSL) apps. The obvious solution is to download the Ubuntu version of Julia and install it on WSL. As soon as I did, I was able to install and run CUTEst smoothly. The compromise is needing two versions of Julia. But Julia is relatively light weight and there's no need to reinstall all the packages just to run CUTEst. Plus, both can run from the same VScode installation. @senna1128 ask me if you try to do it and have some problems on the way.

As an aside, while I was trying to find the right directory for libgfortran, I noticed in the CUTEst.jl documentation (https://jso.dev/CUTEst.jl/stable/) the line for the Ubuntu 14.04 installation:
sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/$(gfortran -dumpversion | cut -f1,2 -d.)/libgfortran.so /usr/local/lib
Shouldn't it be
sudo ln -s /usr/lib/gcc/x86_64-linux-gnu/$(gfortran -dumpversion | cut -f1,2 -d.)/libgfortran.so /usr/local/lib/libgfortran.so instead?

[abelsiqueira]

Hi @NicolasL-S, I'm glad to hear this. Maybe the solution to this issue then would be a note on the installation documentation to use WSL on Windows and install Julia on WSL? Let me know what you think.

About the ln -s command, if you give a directory as the target, is creates a link with the same name as the source. So the commands are equivalent unless the user doesn't have a /usr/local/lib folder. That being said, it could be clearer to have the second option. Let me know if you're willing to make a pull request to change it.

Thanks for the help.

[NicolasL-S]

Hi @abelsiqueira,

Sure. I just pushed some proposed changes to the docs; feel free to edit as you see fit. It's hard to go too much into detail. I'm learning as I'm going and there are so many possible versions of Linux, WSL/WSL2, gfortran, directories, etc. Some prior knowledge must be assumed from the users.

For the Ubuntu 14.04 installation, no need to change the line if it works.

[abelsiqueira]

Hi @NicolasL-S, where did you push them? Can you make a pull request? It is easier to suggest modifications and accept your changes that way.

[NicolasL-S]

Sorry, I just did, I think it should work now.

[abelsiqueira]

Thank you, @NicolasL-S. I accepted the PR, it looks great, and it should help Windows users get started. More info would be hard, indeed.

I'm closing this since we figured out the problem and created a workaround.