Open bit-web24 opened 1 year ago
Been there done that. The Julia team has their own agenda and support for MinGW is purely a superficial bait-and-switch to their paid support libraries under guise of open source IMO.
I have extensive notes about the work-arounds and if there is enough interest I might add it to a project.
Julia wasn't updated in more than a couple of years in MSYS2. And ISTR that even the old version doesn't rebuild. If the old package doesn't even run, would it make sense to just remove it from the repository?
@stahta01: Would you like to have a look?
@stahta01: Would you like to have a look?
I will see if I can get it to build and do a simple run time test.
If someone can post a simple runtime test it will help; I have never really used; I just go it to build a time in the past. Edit: The OP says it errors out just trying to run the app; so, I can at least verify it fails that way and look for that cause. Edit2: Confirmed problem in MINGW64; MINGW32 does not have the problem. Edit3: Package no longer builds for MINGW64(Looks like internet download issue); I will see if any of the newer version builds. Edit4: version 1.6.7 almost builds; decided to build 1.8.5 and patch it for the LLVM 15 issues. Edit5: It looks like I will have to create an llvm-julia package to make the work easier and faster It will be julia fork of LLVM 13.0.1 with the patches needed by MSys2 MinGW64 etc.
Tim S.
@stahta01 as I already said this is how julia rolls. Even if you do get it to build again just by chasing source package URLs, it probably won't last for very long and you will back where we are now. Besides, 1.4.1 probably won't get any support from them beyond "wow 1.4 is so old you should be on 1.8 blah blah ..oh you have to patch it a lot ... sorry we don't officially support that platform anyway". They might actually have a point there, so I finally stopped using Julia, myself..
This is how the folks over at Debian finally dealt with those guys, we might be forced to do something similar: https://launchpad.net/ubuntu/+archive/primary/+sourcefiles/julia/1.4.1+dfsg-1/julia_1.4.1+dfsg-1.debian.tar.xz
Key takeaway: A lot of the necessary external libraries are permanently bundled to the deb-src package so they can't be "removed", and the Makefiles are all patched accordingly.
Building Julia 1.8.5 errors out in LLVM; So, I am creating an LLVM version 13.0.1 package and will see if that can fix the error. Likely have to add patches from Julia to the LLVM13 package to get Julia 1.8.5 to make it past the LLVM errors. No idea how many errors there will be after the LLVM ones.
Tim S.
The temporary LLVM13 package allowed the build to get to the next errors; which is currently Julia build not finding the MSys2 MINGW64 DLLs. I am copying the DLLs to the build bin folder and it is making progress.
Edit1: The current error looks a little like an linker or run-time error that I hope goes away once I copy all the DLLs that Julia looked for during prior build steps. Edit2: Copying the DLLs did not fix the problem; trying to use new value for make "LOCALBASE" setting. Edit3: Copying the DLLs did change the problem to sys.dll not being found; instead of the copied DLL not being found.
Tim S.
I am now getting the bootstrap version of julia.exe to run; it crashes at once. So, the rest of the build fails. I am going to replace some of the software built locally by the Julia package with MSys2 MINGW64 packages and see if the crash will go away. I also will try to build from the MINGW64 prompt the Julia git repo using the Julia recommended way and see if that works.
Tim S.
I think the simplest way to use Julia on MSYS2 without looking inside is to download the latest tarball of Julia for winx86_64, extract it into a fixed path '/opt/' or '/etc/' and export the PATH to that directory.
It's noble that so much time is willing to be spent on this, but I'm trying to help you see it's a fool's errand. Julia is a bait-and-switch to paid support, not true open source. Their team as much confirmed this to me directly when I confronted them on these and other various difficulties. So the source code is all fractured and displaced into different (changing) download locations to prevent anything but the most basic package to be built. Hardly worth it for an actual Julia user and likewise hardly worth it for a MinGW user. I know from experience. Please also review the Debian package I posted.
Something else that you haven't even probably considered. Once you force a round Julia package down the square hole of MinGW, how are you going to load extensions? The last I communicated with their team (in a very long and somewhat confrontational discussion) the package manager as much as admitted that they INTENTIONALLY only supply extensions in BINARY packages and DISCOURAGE unsupported platforms from compiling them from source. Again, there are ways around this but it's always like trying to "hit a bullet with a smaller bullet while riding horseback". In a year's time you will very likely be right back to where we are now. I'm not trying to be mean, I just don't see that value add here...
Julia 1.8.4, 1.8.5, 1.9, and git master all have this bug msys2+mingw64 build failed.
I am trying 1.8.3 and I think that bug does not exist in it. Edit1: 1.8.3 does not have that bug; MINGW64 build of my updated package is doing check; it looks like it will take many hours to finish the check. I am partly afraid the installation will have issues. Edit2: The make install command failed; should be easy fix.
Tim S.
Please give feedback on the PR I just submitted PR 15343
It builds and I ran it under both MING64 and MINGW32; but, I did 2 or 3 minor changes since I last ran both builds.
Tim S.
Since Cygwin is before MSys2 in the apparent support by the Julia project, I am going to try building Julia under Cygwin. I hope to learn enough doing that to help building UCRT version of package.
I am working on testing my last Julia package changes; once I test both MINGW32 and MINGW64 work for simple hello world test, I will remove WIP so others will test it.
Tim S.
The PR is ready to merge it would have been nice if some tried the package and gave feedback. I am thinking that my work was a waste of time and effort.
@mmuetzel I hope the package works well enough; but, since I got no user feedback it is guess.
Tim S.
I am thinking that my work was a waste of time and effort.
I do not see any value of your posts in this thread!
Tim S.
That's too bad, since you could have avoided spending so much time on this.
Also, as I tried to help you see before, or maybe you even already know, but Julia isn't just a basic one-and-done dependency library. It's a whole platform, and won't be much use beyond window dressing without proper upstream support and a reliable means of extension - both of which MSYS2 lacks. The first thing that the Julia team tried to do when I approached them about this was try to get me to just use their supported MSVC platform. It would be wonderful if the world was different but this is how it is now.
@stahta01: I'm not a julia user myself. I was just asked to ping you before potentially removing the package from the repository. I'm sorry for not having given more background before.
I downloaded the MINGW64 build artifact from the "Artifacts" dropdown list near the top of this page:
https://github.com/msys2/MINGW-packages/pull/15343/checks
After they were downloaded, I un-zipped the file and installed it with pacman -U mingw-w64-x86_64-julia-1.8.3-1-any.pkg.tar.zst
from a MINGW64
prompt.
When I try to start julia
now, I see the same error from the original message:
Markus@Markus-PC MINGW64 ~
$ pacman -U mingw-w64-x86_64-julia-1.8.3-1-any.pkg.tar.zst
Pakete werden geladen …
Abhängigkeiten werden aufgelöst …
Nach in Konflikt stehenden Paketen wird gesucht …
Pakete (1) mingw-w64-x86_64-julia-1.8.3-1
Gesamtgröße der installierten Pakete: 287,20 MiB
:: Installation fortsetzen? [J/n]
(1/1) Schlüssel im Schlüsselbund werden geprüft [####################################################] 100%
(1/1) Paket-Integrität wird überprüft [####################################################] 100%
(1/1) Paket-Dateien werden geladen [####################################################] 100%
(1/1) Auf Dateikonflikte wird geprüft [####################################################] 100%
(1/1) Verfügbarer Festplattenspeicher wird ermittelt [####################################################] 100%
:: Paketänderungen werden verarbeitet …
(1/1) Installiert wird mingw-w64-x86_64-julia [####################################################] 100%
Markus@Markus-PC MINGW64 ~
$ julia
ERROR: Unable to find compatible target in system image.
Markus@Markus-PC MINGW64 ~
$ which julia
/mingw64/bin/julia
Do I need to do something more?
It runs locally; but, my internet connect is not good enough to download the CI built package.
Tim S.
Hmmm. Maybe, there are some relocation issues. Does it still work for you locally if you install the package and move (or remove) the source and build tree?
Anyway: If this isn't an easy fix, it might not be worth putting too much effort into it if you aren't a user yourself either. After all, it took probably more than a year for someone to notice that the currently packaged version doesn't start. So, there are probably not many users of the julia package from here out there...
I am closing the PR and opening one in dev so my 30 hours of work won't be lost. I figure maybe someone else will work on finding the cause of the issue. It would help if this thread bull shitter stops posting lies and/or misinformation.
Tim S.
Also, as I tried to help you see before, or maybe you even already know, but Julia isn't just a basic one-and-done dependency library. It's a whole platform, and won't be much use beyond window dressing without proper upstream support and a reliable means of extension - both of which MSYS2 lacks. The first thing that the Julia team tried to do when I approached them about this was try to get me to just use their supported MSVC platform. It would be wonderful if the world was different but this is how it is now.
Why are you spreading lies or misinformation?
The Julia people build on Linux not MSVC! On windows, it is WSL, Cygwin, and last MSys2 for the supported build method. Per Julia discussion forum or issue, MSys2 has been broken for about two years. Building all of the source on Cygwin is currently partly broken; there is someone with PRs to fix most or maybe all of CYgwin build issues in git master branch.
Tim S.
Also, as I tried to help you see before, or maybe you even already know, but Julia isn't just a basic one-and-done dependency library. It's a whole platform, and won't be much use beyond window dressing without proper upstream support and a reliable means of extension - both of which MSYS2 lacks. The first thing that the Julia team tried to do when I approached them about this was try to get me to just use their supported MSVC platform. It would be wonderful if the world was different but this is how it is now.
Why are you spreading lies or misinformation?
It wasn't intentional. I simply made that assumption when they completely stonewalled my efforts to compile native extensions under MinGW. The MSVC assumption was mine based on process of elimination, as nothing else could explain the response I got. But it doesn't change anything else I said. The last build is indeed MSYS looking at the latest portable binaries:
@^@GCC: (Rev1, Built by MSYS2 project) 12.2.0^
Which makes it really weird that I couldn't get any help from them for MInGW two years ago!
It will be best to wait (julia devs) for official julia support or community support. As no package can grow or will well function without the community support.
I have gotten 1.9.0rc1 to build for MINGW64 and MINGW32 using only a very minor change from Julia build methods. And, I found out someone recommend VS Code as the IDE/Editor to use for Julia program development which might be why another poster in this thread thought MSVC was needed to build this package.
Also, got UCRT64 package to build using unapproved methods as judged by the Julia Team.
Tim S.
To resolve this issue, you can try the following steps:
Check the system architecture of your machine by running the command uname -m in the terminal. If it returns x86_64, then you need to make sure that you have installed the 64-bit version of Julia.
Uninstall the existing version of Julia from your system using the package manager.
Download the latest 64-bit version of Julia for Windows from the official website: https://julialang.org/downloads/.
Install the downloaded Julia package and try running the REPL again.
If you still encounter the same error, you can try posting a detailed report of the issue on the Julia GitHub repository or submitting a PR if you have identified a fix for the problem.
To resolve this issue, you can try the following steps:
Check the system architecture of your machine by running the command uname -m in the terminal. If it returns x86_64, then you need to make sure that you have installed the 64-bit version of Julia.
Uninstall the existing version of Julia from your system using the package manager.
Download the latest 64-bit version of Julia for Windows from the official website: https://julialang.org/downloads/.
Install the downloaded Julia package and try running the REPL again.
If you still encounter the same error, you can try posting a detailed report of the issue on the Julia GitHub repository or submitting a PR if you have identified a fix for the problem.
Your reply makes no sense; I am creating the MSys2 MINGW package!!
Tim S.
Hi @stahta01, I wanted to thank you for your efforts in helping the julia community in this work, and for posting your code at https://github.com/msys2/MINGW-packages-dev/pull/33 I think you've achieved something that even julia devs have found difficult. Let me know if I can help, including testing.
Hi @stahta01, I wanted to thank you for your efforts in helping the julia community in this work, and for posting your code at msys2/MINGW-packages-dev#33 I think you've achieved something that even julia devs have found difficult. Let me know if I can help, including testing.
I just updated my PR here 16170 once it finishes can you test one of the 64 bit packages and verify it work?
Thank you.
Tim S.
After all, it took probably more than a year for someone to notice that the currently packaged version doesn't start. - @ mmuetzel at https://github.com/msys2/MINGW-packages/issues/14942#issuecomment-1426029054
$ pacman -Ss julia --color=always | grep julia
mingw32/mingw-w64-i686-julia 1.4.1-3
mingw64/mingw-w64-x86_64-julia 1.4.1-3
the currently packaged version is 1.4.1 from 2020-04, no normal user will use that old software - especially for a language or an interface which can evolve.
@stahta01 Hi, I tried to test by downloading the MINGW64-package here. I received the error:
$ ./mingw64/bin/julia.exe
ERROR: Unable to load dependent library .\mingw64\bin\../bin/libgcc_s_seh-1.dll
Message:The specified module could not be found.
As the message says, libgcc_s_seh-1.dll
is not present in the package version. If I copy that library in from a julia distribution, the julia runs but then errors with
InitError(mod=:LibCURL_jll, error=ErrorException("could not load library "libcurl-4.dll"
The specified module could not be found. "))
even though this time libcurl-4.dll
is present.
@stahta01 Hi, I tried to test by downloading the MINGW64-package here. I received the error:
$ ./mingw64/bin/julia.exe ERROR: Unable to load dependent library .\mingw64\bin\../bin/libgcc_s_seh-1.dll Message:The specified module could not be found.
As the message says,
libgcc_s_seh-1.dll
is not present in the package version. If I copy that library in from a julia distribution, the julia runs but then errors withInitError(mod=:LibCURL_jll, error=ErrorException("could not load library "libcurl-4.dll" The specified module could not be found. "))
even though this time
libcurl-4.dll
is present.
Thank you very much for feed back.
Could someone test the PR 16170 it is much newer than what was tested two posts above, thanks!
Hi @stahta01 , I have tested this out now. I am able to launch julia.exe
from .\libexec\julia\bin
. Well done!
(This path is a bit non-standard, usually the julia executable is located at .\bin\julia.exe
).
However, when trying to install and precompile packages I get this error:
lld: error: unable to find library -lssp
(@v1.9) pkg>
┌ Error: Pkg.precompile error
│
└ @ Pkg.API C:\mingw64\libexec\julia\share\julia\stdlib\v1.9\Pkg\src\API.jl:1289
Hi @stahta01 , I have tested this out now. I am able to launch
julia.exe
from.\libexec\julia\bin
. Well done!(This path is a bit non-standard, usually the julia executable is located at
.\bin\julia.exe
).However, when trying to install and precompile packages I get this error:
lld: error: unable to find library -lssp (@v1.9) pkg> ┌ Error: Pkg.precompile error │ └ @ Pkg.API C:\mingw64\libexec\julia\share\julia\stdlib\v1.9\Pkg\src\API.jl:1289
The MSys2 MinGW Team decided to stop providing the ssp with GCC; this error is likely related to that change. If you post the steps to duplicate I can see if I can find a fix or workaround.
NOTE: I am not a person who has use Julia; I have just built it and learned a tiny bit doing that.
Tim S.
If someone is still interested in packaging Julia, maybe the comments in the following issue could help: https://github.com/JuliaLang/julia/issues/52279
I am no longer interested; the Julia way and the MSys2 MinGW way of building is just too different.
Description / Steps to reproduce the issue
mingw64/mingw-w64-x86_64-julia 1.4.1-3 [installed] High-level, high-performance, dynamic programming language for technical computing (mingw-w64)
After installing and running the above pkg it is showing the following error:
bitwe@system76 MINGW64 ~ $ julia ERROR: Unable to find compatible target in system image.
Expected behavior
I had expected to open the Julia REPL
Actual behavior
It is showing an error with the following text:
'Unable to find compatible target in system image'
Verification
Windows Version
MINGW64_NT-10.0-22621
MINGW environments affected
Are you willing to submit a PR?
No response