-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Issues with "Linux Cross-Compile" (Debian WSL) #7526
Comments
This could have something to do with versioning (Bullseye, Buster, etc), but I don't know. |
Solved it with
|
Fixed with |
Then running
WSL uses Bookworm:
|
Tobydox's PPA is for Ubuntu 20.04 (focal), not Debian 12 (bookworm): https://ppa.launchpadcontent.net/tobydox/mingw-w64/ubuntu/dists/focal/ It looks like @FyiurAmron erroneously changed the wiki article to say "Debian" rather than "Ubuntu" starting with this revision: https://github.com/LMMS/lmms/wiki/Dependencies-Windows/4b141b4f8fb77c9cd46799e2e87f6a9499dcd03a I just changed it back to "Ubuntu". While you probably could get it to work on Debian, we do not officially support anything other than what our automated builds use, which is Ubuntu 20.04. |
@messmerd FWIW, you're completely right here, I tried to recall why I changed that but couldn't find any rational reason, probably were just editing 3 pages at once and went on a spree and done this due to some brain fart. Maybe I wanted to describe the exact procedure for normal Debian distros in-depth and either forgotten about that or gave up on it, or maybe it was just a completely random mistake. Can't recall now, the last months been hectic for me. Anyhow, I 100% agree, although technically Ubuntu still is Debian, just repackaged :D (and yes, with the deps either built from source or otherwise repackaged, I see no reason why it wouldn't work, but I also see no reliable way to support people doing that since I'm not using raw Debian on a daily basis anymore and I guess it's an edge case anyhow) @bratpeki tl;dr those PPAs are a relic from the past, so compiling them libs from source would be your best bet - but while you could do that or even try to configure APT to fetch those for |
Excellent, thank you both! I'll move the compilation process to MSYS, then! @FyiurAmron, where can I find relevant documentation, if any? I'm persuming MSYS2 is focused on using Pacman, so I could get the dependency list off the lmms-git AUR repo, but is there anything on the LMMS Wiki regarding this? |
@bratpeki doh! Now I recall, I was in the process of updating those docs when RL stuff struck me. Found some commented out doc blocks hinting on what I wanted to do next, and it was indeed providing docs for MSYS process, and perhaps Debian afterwards. It's quite straightforward for MSYS anyway and strictly follows what's described on https://github.com/LMMS/lmms/wiki/Compiling for other compile paths; I'll post you the exact file I guess was supposed to be the basis of the doc:
After getting the libs installed, prepare the dirs for make ( If it works for you, feel free to add this or any other relevant data to the wiki as new section. We had some outdated docs for MSYS in the olden days, but https://github.com/LMMS/lmms/wiki/Dependencies-Windows/_compare/a857e2562de0d13a5387d75db2508c9cf7127641...6cfbc94f040dce913ab456429c1b2b897dad1167 removed them a couple of months ago (not that it was a wrong call by itself, that part was outdated as hell and was also mostly unnecessary anymore). |
Wonderful, thank you! I'd help you keep the building Wiki page up-to-date, if necessary, and I believe the cmake commands should be different, to specify the output binary is a Windows one! |
I believe I should either choose 1 or 3, looking into it now. |
@bratpeki From what I recall, MSYS's cmake can only output Win32/64 binary, so no need to instruct it to do so. The commands should work as-is (maybe you'll need to tell CMake to use Unix buildfiles instead of Ninjas etc., but YMMV there, I just didn't have any luck with Ninja builds, some random errors started happening). |
You'll need all 13 of them IIRC. Some are optional-ish (gdb e.g.), but most of them are strictly required, and there is no harm in having them all anyway. |
After finnicking around with my antivirus software, I am pleased to announced I've compiled it! The instructions were straight-to-the point, with the exception of having to restart! |
When attempting to run from the |
TBH, I never had to do that for MSYS, but obviously YMMV here, I'm still on old-ish MSYS version on Win7, maybe Win10 version changed something, maybe you were just unlucky with your particular setup for some reason.
It should be possible on both. However, to do that on Windows you'd have to have a dir with those DLLs in a shared location (i.e. on Windows PATH) for this to work without having the DLLs bundled in the same dir. That's one way to handle it, althout some files required for "normal" LMMS work might be missing anyway (I'm not using this one personally for that reason). Another way is to use CMake to create an NSIS build to get a complete package with all the DLLs bundled. AFAIK you'll get all the needed files in Yet another approach is to just copy the exe from build to an existing 1.3.0-alpha install location and either overwrite the old one or rename one of them. This one should be fool-proof as well, drag-n-drop or one-liner is needed only. Renaming the exes allows you to compare the different build versions side-by-side as well too, so it's a 10/10 approach in my book. You might also mix the above solutions in any way you fancy, obviously. Do what suits you best. |
Or you can just |
@Rossmaxx a very good point. So, in total, that's at least 4 reliable methods to handle this. Should be enough :D |
Thank you both! This works like a charm with an out of the box MSYS2 install. I think I could write up an addition to the PR, as this seems like a very easy way to get building up and running on Windows! I'll give Ross' command and packaging a shot, and let you know how it goes. |
Works like a charm! |
I have utilized the following build rules, and I'm just sending them to have them saved and formatted, as well as present my progress:
mkdir build
cd build
cmake .. -DCMAKE_INSTALL_PREFIX=../target
cmake --build . --target package This makes using Ninja by default and installs the files to
mkdir build
cd build
cmake -G "MSYS Makefiles" ..
make
cmake --install . --prefix "../target/" |
System Information
Windows 10
LMMS Version(s)
Git
Most Recent Working Version
No response
Bug Summary
Following https://github.com/LMMS/lmms/wiki/dependencies-windows#linux-cross-compile to compile on Windows is not straightforward.
I set up Debian using WSL2 on my machine.
The
sudo add-apt-repository ppa:tobydox/mingw-w64
command gives the following result:Expected Behaviour
The command gives no errors, and one may proceed with the compilation steps.
Steps To Reproduce
sudo apt update
andsudo apt install software-properties-common
Logs
Screenshots / Minimum Reproducible Project
No response
Please search the issue tracker for existing bug reports before submitting your own.
The text was updated successfully, but these errors were encountered: