I mean, they clearly are if you’re getting a segfault, no?
I don’t think that’s the issue because we use the FreeBSD 14.2 SDK for building the official libraries, that’s not too much different from what you have. But the libraries may have been built with slightly different options, leading to different expectations between julia’s libraries and your system’s libraries, which leads to the errors you’re observing.
As a general remark, when you have libraries coming from different sources, just keep them separate and live happy, if you decide to mix them up you must be ready to deal with the breakage yourself.
I don’t understand, those libraries were build to be exactly were they are right now. why should i deal with it myself ? if you don’t want to help just don’t no one is forcing you… but don’t expect me to just say OK or not asking question. I want to understand so this way I will not comeback for the same error. It benefit everyone when support is given thoroughly and that the user seek understanding. I mean it’s the mentality of the free and open sources community. If you know where I should look point me there, but don’t say do it be happy or other wise shut up.
may have been … but we not sure so I return to my previous question, how to we know for sure.
The Julia archive is not meant to be merged into the global filesystem hierarchy, even if its internal structure largely mirrors the filesystem hierarchy standard. This is similar to several of the more recent approaches to distributing packages on Unix-like systems, such as Flatpak, Snap, and AppImage. The shared global directories are mainly used by the OS-native package manager, but it takes a lot of coordination between versions and build options to make it work, which is one reason why packages that are distributed in a more direct, less top-down curated way tend to be self-contained and isolated.
Perhaps this paradigm is not yet as widespread in the FreeBSD world as on Linux, so I can sympathize if this feels unusual. However, this is how the Julia archive is intended to be used.
No, they’re not. In the Julia installation they’re in $prefix/lib/julia instead of $prefix/lib precisely not to mess up with other libraries. If you decide to move them elsewhere you then must deal with the consequences of your decision
This folder is supposed to go in /usr/local/lib/julia. Its suppose to be a package for FreeBSD. So normally that package should be in port or in bin. that’s why it has the same structure than the system it goes in.
And if you assert that its not you have to prove it and explain it so I can understand unless your are not capable of it because you’re limited, I can understand that.
Again, if its not than don’t just say its not give explanation or don’t answer at all. til then I will take for granted that nobody know what he is talking about. Again it’s a tar.gz expressly dedicated to FreeBSD so it must be compatible other wise it make no sense.
I am not an expert in any of this myself, but maybe this can be an advantage here…
The people that took their time to answer you do know what they are talking about. So this is not an issue of whether what they say is true or not but an issue of you understanding why.
My (maybe incomplete or even wrong) understanding of this is the following:
Any kind of non-trivial software depends on other libraries and usually all of them come in a myriad of different versions / compiled with different flags etc.
Often more than one program depends on the same library, but in 99 % of the cases it’s not exactly the same version or way it was compiled.
If these mostly the same but not really equal libraries end up in the same directory this causes issues like you witness here.
To avoid that, common package managers have to do a lot of orchestration to make it work.
A different approach to make it work is simply to not put all these libraries in the same place so that each program has a separate set of dependencies that does not interfere with another program’s deps.
Could it - in theory - be made to work for julia according to first way?? Probably.
But the easier and increasingly common method is the second way - keeping dependencies separate.
It may be a fun exercise to re-iterate that it’s a “supported pattern” even when the people most involved with packaging binaries for Julia tell you the opposite.
It comes across quite like insisting that the mini-fridge you bought can be used as a microwave, and then not accepting the manufacturer’s explanation that the fridge actually isn’t intended to be used as a microwave because they don’t give a more detailed answer to “why exactly, it is microwave-shaped, isn’t it?”
I do get your desire to get to the bottom of this and I’m not a big fan of “argument by authority”, but please be aware that if someone well known in the Julia community for in-depth knowledge about how Julia packages it’s binaries tells you that it’s not supposed to work, the reply “you don’t know what you’re talking about” isn’t very constructive and doesn’t put you in the best light
Hi, first I don’t know who I’m talking too, I don’t know who you are and who the previous person before you are neither except that I know that a moderator of the forum has participated in this thread which tell absolutely nothing about is expertise on the topic and his capability to assist the issue correctly. The "spotlight "can be on me, meaning, you can have the opinion you want about me, it’s irrelevant and I don’t care. The problem is that for sure all the people that answered this request for support t’ill now seemingly don’t know what they are talking about, even you because they can only give authoritative direction an adhominen argument. As for you example it is totally exaggerated, out of context and insulting. comment like yours only participate to deviate from the main issue and doesn’t help. I still don’t have any satisfying explanation to my question and no solution has been found because of that. I’m not the one who is in fault for that. A Message for you and everyone: Please refrain for adding more personal comment or opinion on that thread. If you absolutely feel the urgency to tell me your opinion go through the appropriate Chanel that is the private message. I will now only answer support message that address the issue. Thank you for your understanding.
It states that you untar the tar ball and get a directory, it then goes on to state:
Note that it says that Julia installs all its files in a single directory. And there’s nothing about moving files around. It might be possible, but then you may have to mess around with ldconfig or LD_LIBRARY_PATH, LD_PRELOAD or similar things to get things to work.
Julia is generally not compatible with other libraries because it uses custom patches for some of them. I am not deeply involved so I can’t tell you everything that is customized but most notably LLVM is customized. This why most of the times when people use their distro’s package manager to install Julia, Julia crashes as soon as the compiler is invoked.Yours seems to crash later, so you probably load the correct LLVM but something else is off.
To circumvent all of these library versioning/patching issues, Julia comes with all libraries it needs in the correct version in a single archive. Julia also looks for its libraries in that folder. So if you rip it apart and place the files elsewhere then Julia likely falls back to searching for libraries in generic places and loads whatever it finds. If you had another version of LLVM installed, then you would not have gotten so far as to install Pluto.jl at all.
So to fix your issues, just extract the archive and don’t make any changes to the structure. Use a symlink to link the binary to whereever it needs to be for your system to find it and then be happy.
I see, thanks for that. Did not read it correctly the first time, what got me wrong is that in the example for Linux the path where the extraction is done is in root/bin. And I was reading the man hier page in FreeBSD and wasnt able to find were to put it in the system file cause the only place were it seemed logic to put them according to my interpretation of the information provided by the manual page was /usr/loca/and so on. Even if it specified that this path is for package from pkg and port. I forgot that I have also a bin directory in my ~/ dir for outsider package. so I deleted the the files and folders I previously wrongly put in the /usr/local dir and moved the julia folder in ~/home/user/bin and added the /home/user/bin/julia.1.11.6/bin to the $PATH.
To finish the follow-up on the installation of juliaup following the instruction on the GitHub page and installing the default setting did the job, but one have to read the prompt carefully to be sure that the default correspond to is setting, which was my case the proposed addition in .profile is not needed for me. The only thing I had to do is adding juliaup’s bin dir to the PATH.
Also one thing that might be confusing is that juliaup is an independent program in its self so it runs independently of julia, not inside.
