Rack support needs to be made aware, I’d say.
1 Like
VCV ppl - I do really need to figure out how to email a bug report, or do the relevant people already know that VCV has not been able to build on windows for months?
You can use the form here
or mail support@vcvrack.com. I use the form to avoid getting sent to their junk mail.
oh, nice!
1 Like
done!
1 Like
Let’s hope Rack can easily be built on Windows again soon 
well, as you said, need to update the dep that’s bad (was it curl?), then hope any changes there don’t ripple out, right? I know at work we let some of our third party stuff get pretty old, so when we finally do update any it might change like 50 files in our own code…
Yep, it’s curl.
I feel the pain for the ripples :S
As maligned as Windows is (at times quite deserved)… one thing, I think, they got absolutely right from its inception was compatibility: implementation might suck (particularly as of late); but most interfaces are NOT changed (at least the documented ones… the others… well, they are “secret” for a reason), if new features are added, new interfaces are provided so the old ones work.
Really old 16 bit programs still work under 32 bit OS versions and some mad devs. Have updated some to 64 bits…
Some commentators hail the year of the Linux desktop… every year… I don’t think that will happen until backwards compatibility is a paramount feature (as well as some desktop UI standardization). This problem affects a lot of free software (SDL? Allegro? Gnome…). Yep… I’m a heathen and should burn at the stake; but having to redo UI metrics for every WM out there… is not at all a source of happiness.
We all know Apple doesn’t particularly care for that so… yeah.
C++ is also guilty of this, but that’s a story for another day.
I don’t know. As a longtime windows user I used to think backwards compatibility was worth it. But as you say, look at apple. They are never ever backwards compatible with anything and they are kicking butt, and ppl like their products.
Clearly… I’m not fond of them :P.
Having to renew certain software every once in a while can be annoying but manageable (sometimes expensive).
Having to renew your hardware (say, audio gear) because they remove, for example, firewire support… not so manageable at times (and, often, more expensive).
I honestly don’t think they have really good gear, or software for that matter (expensive as it is); great marketing… that they do have.
1 Like
The way I always thought of it is there’s the following strategies
Windows: every api ever is always available. Pro loads of comparability, con you get interfaces like IDirect2Dfontmanager27. Con things like transition to arm are basically impossible to do quickly and the dev tooling is inconsistent (cmd, powershell, mysys, visual studio, git bash, and visual studio cmd all come into play for me using the system)
macOS: there’s an api which is at the tip. You pick your minimum os at compile time. APIs go away so the wavefront pushes forward. Pro: they can make sweeping uniform improvements in your platform. Con: developers have to always be porting. Maybe pro maybe con: this only works if they own the hardware (but these arm chips are amazing!)
Linux: well Linux doesn’t actually exist. There’s a kernel and a set of choices you can make. Any given ostensibly Linux box will have radically different capabilities and APIs available depending on those choices. Pro: super customizable. Con: binary distribution of software is roughly impossible if you want to get all the configurations so you lowest common to Ubuntu 16 or 18. Maybe pro maybe con: virtualization (docker, flatpak) make this irrelevant and you run each program in essentially an independent copy of the os.
Which is best? That’s foolish to try and answer. But I think that’s a way I’ve found to think about the oses when participating in cross platform desktop projects
2 Likes
Thanks for skimming and reporting the error messages.
After searching for version history of curl only found:
https://repo.msys2.org/msys/x86_64/
curl-7.85.0-2-x86_64.pkg.tar.zst | 21-Sep-2022 |
Why is thre no version of curl-7.79.0-1, strange.
So stopped tinkering around.
Mingw offers up to version 8.8.0-8; but that is irrelevant for this case: the problem lies with Rack trying to build its own 7.79.1, GCC 14 refuses to compile versions that old, at least under mingw.
Well said.
Is that true? Or is it “only works if you don’t let/encourage third parties to write device drivers”? I think the lack of device drivers is a different pro / con?
Well. I think its turned out to be true, but yeah is it a necessary condition? Interesting question.
So for things like touch id, graphics performance and APIs and so forth baked into the OS you definitely need some things where you control the manufacturing pipeline. Also allowing multiple devices but no device drivers wont work, so you would at least need to certify hardware with this strategy if you don’t produce it, I think. There’s also the corporate idea that if Microsoft says “everyone needs to use ARM” 1000 manufacturers can say “meh” but if apple says it, their engineering team says “yes boss”, so it’s a heck of a lot easier to change if you control the hardware.
So maybe necessary, but definitely way way easier.
(From a marketing perspective, it also helps that their hardware is fantastic. The M1Max MacBook Pro I have is probably the biggest single computer upgrade I’ve experienced since going from a sunos workstation to an SGI Indy. But YMMV).
The other thing which ends up happening is you can specify and test standards-compliant APIs and drivers. We have a lot of users of surge. We get a lot of ASIO questions, a lot of jack/alsa/pipewire/etc… questions but I think we’ve never ever had a CoreAudio question. It really does “just work” it seems for the users who reach out to us for support.
Anyway like I said, I don’t know if it makes sense to say which strategy is “best”. I’ve definitely found it useful to have the ultra-tweaking of linux in many situations (none of which are distributing binary software to the desktop though); and I’ve loved macOS since 10.4 or so and the switch to intel (when I finally dumped the intel box I had which was running gentoo (!!)). So I know of the 3 which 2 I prefer, and of those 2, which 1. But it’s not like I think mac is “better” just “it works better for me”.
1 Like
I had this exact same problem and got around to successfully building rack. I downgraded GCC like @Bloodbat said, and then after that curl was my main issue.
Most things would build in dep, but curl stopped the build in its tracks. When I ran make it let me know which .a files were missing from /dep/lib, so I went into those submodule folders and ran make on each of those. Everything except curl should build fine.
As a note, some of the .a files expected in /dep/lib are in the /mingw64/lib folder. You can copy those over. You’ll know if the build doesn’t like it when you run make because it’ll error out. The copy was good for pretty much everything but libcurl.a, since Rack sends custom config during the build that isn’t in the default libcurl build.
This is where I’m not sure what fixed curl, but I ran the downgrade on it to version 7.85.0 (mingw-w64-x86_64-curl-7.85.0-1-any.pkg.tar.zst in the index). After that I ran a make clean in the /dep/curl*/ folder and ran make on it and the dep build worked. Running make on the full repo ran cleanly after that.
Sorry I couldn’t be more detailed for the final fix, but it was sort of like trying multiple fixes at once, so I wasn’t sure what actually fixed it.
The explanation is here:
Apparently it’s autotools’ fault? Maybe, just maybe, using their diff to patch curl-functions.m4 could fix compilation and, if so, help VCV fix the bug report @Squinky posted.
I’m sorry, I don’t have time ATM to nuke my Rack deps and build the whole thing again. If you do, let us know if it works, please.
I applied the diff in that issue and it didn’t really fix anything. I’ll do a full clone and rebuild in another directory. I’ll let you know my findings.
I rebuilt and I still ran into the same problem with curl after applying the patch. Not sure how it suddenly worked. What I did the first time was I ran make after the deps failed and simply went through and updated all #include references directly to the dependency. Then I got make to work until it couldn’t find the .a files it needed.
I guess the easiest path is downgrading GCC while we wait for VCV to fix the dependency?