Defining an MSYS2 build command list #7526
Comments
|
This could have something to do with versioning (Bullseye, Buster, etc), but I don't know. |
bratpeki
changed the title
|
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? (Update: MSYS' Pacman is definitely not housing the same packages as Arch's Pacman, for anyone learning about it and reading this in the future, LOL) |
|
@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 packageThis makes using Ninja by default and installs the files to
mkdir build
cd build
cmake -G "MSYS Makefiles" ..
make
cmake --install . --prefix "../target/" |
|
So can we close? |
|
Just let me make a proposed edit to the Wiki and we can close! |
Morbid curiosity, but why not use an Ubuntu WSL instance? |
|
I am also intending to try an Ubuntu WSL, since I made an issue of trying to compile on Debian, which isn't officially supported. I realized my mistake only recently, and forgot to write about it. Thank you for commenting, that reminded me to write! Also relevant:
|
|
Also, @FyiurAmron generally recommended MSYS, saying that the PPAs are "a relic of the past", so I'm intending to provide both compilation methods, if compiling with the PPAs is still possible. If I have trouble we can't overcome, MSYS has proved to be ridiculously simple! |
This may be a bit outdated (6 years old) but here's how I did it last: https://gist.github.com/tresf/3c739a739b56d8dc0679c3f2f85c349d |
For cross-compiling, I'm unaware of an equivalent to Toby's PPA. I think cross-compiling is a nice option however we may decide to remove if if keeping the PPAs around is too much work. |
|
(should be run under ucrt64 or clang64) I could contribute a CI build if anyone wants Edit: after a while I somehow couldnt reproduce a build anymore... I have no idea why the first time compiled however~~ Edit:I have no idea why I could build the first time but not the second time. Here is however my recipe again |
|
@Kreijstal could you give my recipe above a try on a clean MSYS2? I'm planning on doing so myself as well, when I find the time. I'll try making a |
the second recipe I did seems to work on clean msys2 |
|
Oh, dope! I'll run it on a clean MSYS2 as well and if all goes well, I'd say that's a candidate for a native Windows build recipe. |
|
Running under UCRT. I ran your |
|
The building with @Kreijstal's commands was a success! I do still wonder why the additional I'll experiment with it some more and report back. In the meantime, I'm curious as to how @tresf, @FyiurAmron and @messmerd feel about including the MSYS2 building as part of the Windows building instructions on the Wiki. Do you think it's a good addition? If not, why? Asking mainly to know if this is fit for closing after looking into what I mentioned above. |
|
Checked if building fails without the |
Yes, please. |
I already started adding them during the summer, just didn't have time to finish. Obviously I feel it's a good idea to document it, otherwise I wouldn't have started to do so myself (there still should be some commented-out sections with link in preparation for the new paragraphs etc. I think that were prepared by me there)
Yes. See above. Would have done it myself if I had the time. I still stand by what I wrote near the beginning of this thread:
|
it is indeed a mystery the first time I build this I didnt need to do any sed logic, it simply compiled out of the box, then I tested on another system and it stopped working! I tested on the original computer where I built it and got the same error... I have no idea. |
bratpeki
changed the title
|
I tried running @Kreijstal's commands for MINGW, even if they aren't intended for it, just to see what would happen, and: Just noticed my commands (#7526 (comment)) don't address That being said, since |
libgig is definitely in msys2/mingw64, that's what the pacman -Syu is for |
Just looked this up and wanted to share...
As Windows 10 (and thus 32-bit) nears EOL, I'm curious if they'll keep this mindset or turn it off. My instinct is that it'll default to only |
if you are on ucrt64, it defaults to ucrt64 :p means current enviroment, if you are on clangarm64 (windows on arm) :p will install arm packages. Ahh.. yeah they deprecated mingw32 and mingw64 (sadly), maybe there will be a msys2 fork that supports mingw32 packages. |
I can't answer this mystery, but I did check upstream and there are several references to https://github.com/search?q=repo%3Azynaddsubfx%2Fzynaddsubfx+windows.h&type=code
We'd happily accept this in our fork. |
|
Pushed the commit to my fork. @Kreijstal, please apply this and let me know how it goes on a clean MSYS2 of any kind. diff --git a/src/UI/common.H b/src/UI/common.H
index 4a077e32..4f6e3465 100644
--- a/src/UI/common.H
+++ b/src/UI/common.H
@@ -20,6 +20,10 @@
class Fl_Widget;
extern void set_module_parameters ( Fl_Widget * );
+#ifdef WIN32
+#include <windows.h>
+#endif
+
#ifdef FLTK_GUI
#define fl_color_add_alpha( x,y ) x
#undef FL_NO_BOX |
|
Tried the build myself, and it seems to be just fine! I'll make the PR to the Zyn submodule, where this can be discussed further. |
even those that still support 32bit are only supporting it till windows 10 jeremyd2019/msys2-build32#3 (comment) remember that lmms should use less than 2gb of ram.. for it to work on 32bit |
Right. For clarity, LMMS will continue to support the very popular 32-bit VST2s through the 64bit-32bit VST2 bridge for the foreseeable future. |
so you are not interested in a full 32bit build of lmms just the vst32 bridge? |
Correct. We never need to support a 32-bit OS again but some really good plugins were only ever released as 32-bit. |
|
@tresf TBH I always wondered why no-one (at least no-one I know of) ever did a 32->64 static recompiler for Win VSTs. I mean, it's no trivial task, and the 32->64 bridges (or even VMs/compat layers) already fulfil the role, but I haven't even heard of such project being done TBH, and with VST SDK freely available, wouldn't be that hard, honestly. Perhaps it's just that - it wasn't really needed, so nobody did it... however, I think that if I were still a grad student today I would do one for a course project probably, just for the sake of it xD and, before anyone says "but it doesn't make sense to do static recompilation at all..." - well, actually I'd beg to differ :D |
VST2 is
Gut instinct is that it's not a problem that needs solving as long as these OSs can still execute 32-bit instruction sets. Mac killed off 32-bit instructions sets at the OS-level and then later on the hardware-level (the latter of which prevented some older 32-bit apps on Windows 10 ARM64 from running in a VM on a Mac host -- all of which has been fixed in Windows 11 😅). If 32-bit instructions vanish from WIndows, there may THEN be a demand, however they've maintained backwards compatibility for decades and people just rely on it. Even as a software developer, I shamelessly use 32-bit Intel installers for both AMD64 and ARM64 Windows. 🤷 AFAIR, steam does this too. |
well if the source code is not available then it can't be packaged on msys2... but yeah there will be alternatives eventually :) |
In my (limited) experience, most VST2s source aren't made available. |
How did LMMS not get included in this? |
Luck, I think. |
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-w64command gives the following result:Expected Behaviour
The command gives no errors, and one may proceed with the compilation steps.
Steps To Reproduce
sudo apt updateandsudo apt install software-properties-commonLogs
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: