Summary: | Julia backend does not allow symlinked executable | ||
---|---|---|---|
Product: | [Applications] cantor | Reporter: | hqurve |
Component: | julia-backend | Assignee: | Alexander Semke <alexander.semke> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | alexander.semke |
Priority: | NOR | ||
Version First Reported In: | 23.04.1 | ||
Target Milestone: | --- | ||
Platform: | NixOS | ||
OS: | Linux | ||
Latest Commit: | https://invent.kde.org/education/cantor/-/commit/5c038e422c8fe2fcc14ddca2f8ec8d8c6fbca592 | Version Fixed In: | 23.12 |
Sentry Crash Report: | |||
Attachments: | Screenshot showing that the julia backend works with symlink |
Description
hqurve
2023-05-28 23:27:28 UTC
(In reply to hqurve from comment #0) > By building cantor with the logic removed, the julia backend works. However, > I am unsure if this is suitable since I do not know why symlinks are > prevented. This was implemented to make sure Julia's shared libraries are found at runtime. Does Julia backend really work for you if you remove that if check like in your path? Can you try to do a simple evaluation, something like 5+5 is enough, with your patch? It doesn't work for me... 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. (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()? Git commit 5c038e422c8fe2fcc14ddca2f8ec8d8c6fbca592 by Alexander Semke. Committed on 16/09/2023 at 15:09. Pushed by asemke into branch 'master'. [Julia] removed the dependency on Julia's executable and set the recommended version to the current LTS version 1.6.7. We don't communicate via CLI with julia's executable and load the interpreter into Cantor's runtime in the "server" directly and similarly to how it's done also for Python and R. cantor_juliabackend.so and and cantor_juliaserverjulia are linked to julia's libraries. We nowhere depend on the executable. Allowing the user to specify the path to the executable and loading the libraries from there made some edge cases possible but introduced additional complexity in the code and such severe limitation as not being able to work with symlinks in the PATH. So, we remove this complexity and limitations now and the more important option to work with different packages and version of Python, R and Julia will be solved in future differently. FIXED-IN: 23.12 M +3 -0 CHANGELOG.md M +8 -62 src/backends/julia/juliabackend.cpp M +0 -6 src/backends/julia/juliabackend.kcfg M +9 -29 src/backends/julia/juliaserver/juliaserver.cpp M +2 -3 src/backends/julia/juliaserver/juliaserver.h M +1 -5 src/backends/julia/juliasession.cpp M +1 -3 src/backends/julia/juliasettingswidget.cpp M +69 -85 src/backends/julia/settings.ui https://invent.kde.org/education/cantor/-/commit/5c038e422c8fe2fcc14ddca2f8ec8d8c6fbca592 |