-
-
Notifications
You must be signed in to change notification settings - Fork 5.6k
Should julia_home
point to the root rather than the bin
directory?
#9981
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
This thought has occurred to me before too, and it sounds like the reasonable thing to do. |
the problem with it pointing a "level higher" is that it no longer points to anything at all. there is no particular guarantee that the file layout will have a bin/ or lib/ folder from that point. currently, JULIA_HOME is used to locate the moving the sys.dll/sys.ji files to bin is also fine, although it should be unnecessary. there is never a guarantee either that it will be in the same folder as libjulia.dll, so libjulia.dll-relative paths of |
Distributions can also customize a lot of the layout. Most places that hard-code relative paths are probably subtly wrong and should actually be using relative paths that get saved from build-time information. |
@twadleigh What you want to do looks like a duplicate of #8650. We should definitely provide a simple way of getting the required information to embed Julia. @staticfloat provided a simple command to get the path to libjulia, would it work for you? This kind of information could be made more systematically accessible. |
I seem to remember @waTeim was planning on working on something similar, not sure how far he got though. |
This question arose from working on #9692, in which I'm attempting to get As it stands, unless your embedding executable is in the same directory as the julia executable, things will be broken without an explicit argument to @nalimilan: when embedding, I can get the path to At the very least, we should probably patch the embedding docs to say the |
@twadleigh OK. Looks like #9691 has the solution: use code from #5045 to determine |
Yes the issue @twadleigh was fighting with was the reason for #5045. |
Not only for "regular" distributions. If we use variables from Make.inc, it will work for all distributions which do not move things around after the build (which is a very bad idea). |
still working on it; i had to do other things for a while, but have recently returned to it. It's interesting the different perspectives coming from the windows side and the unix side, my situation is opposite of course, the important part for embedding is where is libjulia not julia the executable. |
If you're embedding though, don't you already have the path to the Julia executable? How are you running the oneliner to get the path of |
Why should one need to know where the This issue might be simple to work around by hardcoding paths. But we really should have initialization as simple as
|
Yes in the library search path, but its not quite that easy for embedding because in many cases libjulia.so may be located in a directory that is not in the list of directories that are automatically searched (e.g. /Applications/Julia-0.3.5.app/Contents/Resources/julia/lib/julia/), the julia executable gets around this by setting rpath relative to itself and that's ok because whatever the particular layout is from one distribution to another the value to set will still be known and under control, but embeddings can be anywhere relative to the executable and the library so have to discover the lib directory and set it explicitly in the link step -Wl,rpath=what goes here? |
Then How does Python solve this? But independent from how to link to |
Assuming that sys.ji is in the same directory as libjulia, then seems like this small change -- "sys.ji" instead of NULL -- would work on OS/X and Linux. (julia_home_dir is where libjulia is located)
But on Windows, I don't know. A lot of this depends on the capabilities of the linker. Maybe on Windows, sys.ji needs be be in the same directory as julia.exe because of this? |
libjulia should be moved to Then |
Careful, it's not just libjulia.so, but all of the other .so in the same directory which libjulia provides an anchor to find, and there are a lot of them. In the case of OS/X in particular, Julia can be/is distributed via Homebrew, but installing Homebrew is asking a lot for someone that just wants to try out Julia by dragging it into Applications. You say executable, which executable do you mean? Julia the executable or the embedding app the executable. Are either of these two strictly speaking necessary? |
I don't understand the problem. I'm not proposing we stop being able to locate libjulia nor
The julia executable. But indeed if the goal is to be able to ship libjulia without the julia executable, we may consider libjulia to be the reference path instead of the julia executable. |
I don't think it's a useful to ship libjulia without julia. That would |
I also don't see a need to ship libjulia without julia but does this mean the module caching will not be implemented in libjulia but in the executable? Would be nice to benefit from module caching in the embedding use case as well. |
@staticfloat : an embedding application can use a system call to find out the path of the .so/.dll that is being called (as, e.g., in the patch in #9692). @tknopp: an embedding application would need to know, as @vtjnash mentioned, the path to the julia exe in order for spawning to work correctly (or, more basically, for the patch in #9692, to get the test suite to pass). |
Stale. |
I'm in the process of trying to get
jl_init
to work without having to provide an argument for the general embedding case.My current patch works on windows because
libjulia.dll
(whose path I'm using to set julia_home) lives in the bin directory there, but breaks on *nix because there it lives in alib
directory.Of course, it's easy enough to patch the
lib
path to get thebin
path, but it begs the question as to whetherjulia_home
should just point to a level higher.One fact in favor of redefining
julia_home
to point a level higher: the majority of references to it begin by appending "..".The text was updated successfully, but these errors were encountered: