https://bugs.kde.org/show_bug.cgi?id=470381
--- Comment #3 from Alexander Semke <alexander.se...@web.de> --- (In reply to hqurve from comment #2) > Created attachment 160673 [details] > Screenshot showing that the julia backend works with symlink > > I attached a screenshot showing that the julia backend is really working and > that the executable is a symlink. > > However, if I do the following, I get an error `Julia session can't login > due internal julia problem with missing internal file - > "/home/joshua/kde/src/lib/julia/sys.so"` > > 1. link julia to the current directory `ln -s $(which julia) ./julia` > 2. add current directory to path `PATH=$(pwd):$PATH` > 3. run cantor and select julia backend > 4. try 1+1 > > From > https://invent.kde.org/education/cantor/-/blob/ > 670993d7bf38afcacd2914509d621761dd8e4e60/src/backends/julia/juliaserver/ > juliaserver.cpp#L27, the error occurs since the .so file cannot be found and > the fallback path is `../lib/julia/sys.so`. > > So, I guess that the issue with symlinks depends on whether you also > correctly symlink the lib/julia/sys.so file. However, the official > installation instructions > (https://julialang.org/downloads/platform/#linux_and_freebsd) for julia only > recommends linking the julia binary and has no suggestions for also linking > the shared library. > > Perhaps the restriction for symlinks could be removed and canonicalPath() > could be used instead of dir().absolutePath() on line 32. (documentation for > canonicalPath https://doc.qt.io/qt-5/qfileinfo.html#canonicalPath). This > replacement allows the julia symlink in my current directory (which is on my > path) to work. Thank you for your valuable input here. I really appreciate it! Switching to QFileInfo::canonicalPath() only doesn't seem to work for me. I'm looking at the logic implemented in JuliaServer::login() https://bugs.kde.org/show_bug.cgi?id=425695 and don't understand the complexity introduced here (I'm not the original author of this code)... Everything works for me fine, also with symlinks, if I replaced that whole logic with the simple jl_init(). With this we don't even need to ask the user to provide the path to the executable. Cantor's binaries cantor_juliabackend.so and cantor_juliaserver are linked against libjulia.so that was used when compiling&linking Cantor and everything else won't work anyway. For python we don't ask to provide the path to the executable. Yes, we can work with one single version of python only that was used during the linking step but this is also true for Julia at the moment - if you select a wrong julia executable it won't work. In future we should be able to support multiple runtimes (different versions of python, julia, etc.) but this is not possible at the moment since we more or less fix the version during the link time and this needs to be implemented differently in future. So, why to ask the user to provide the path to Julia's executable at all and all that complexity with jl_init_with_image()? -- You are receiving this mail because: You are watching all bug changes.
