I’m building rack right now and looking at the commands (and the makefile) it does NOT include debug info by default (you can include it by calling “make debug” if you want to). However… I just got the same error you did.
ah, tx. I just blew away my dep stuff to see if these is something there. don’t know…
My guess is they did something wrong to the compiler, I’ve seen it before. We get the error in different files: src/Quantity.cpp:204:1: internal compiler error: in dwarf2out_frame_debug_expr, at dwarf2cfi.cc:2112 204 | } // namespace rack
Yes, that’s my guess, too.
started from scratch - can’t make the deps.
The solution is to downgrade GCC and its libs, I just managed to build Rack doing that and nothing seems broken.
As with most things MSYS, it’s not straightforward or friendly.
- You need to download by hand, as MSYS doesn’t support downgrading
- mingw-w64-x86_64-gcc-13.2.0-6-any.pkg.tar.zst
- mingw-w64-x86_64-gcc-libs-13.2.0-6-any.pkg.tar.zst
Take heed! There are .sig files with the same long filename… you don’t want or need those.
-
Place the downloaded files in some folder you can access via MSYS.
-
Using msys go to that folder and run
pacman -U -d mingw-w64-x86_64-gcc-libs-13.2.0-6-any.pkg.tar.zst
pacman -U -d mingw-w64-x86_64-gcc-13.2.0-6-any.pkg.tar.zst
Rack and its deps should build.
5 Likes
What version of gcc did MSYS upgrade to that broke the build?
mingw-w64-x86_64-gcc-14.1.0-2 and its libs.
1 Like
MSYS have updated their GCC, version is 14.1.0-3. Rack builds and works fine using that one.
1 Like
I have that version (now), but I still can’t build the deps. what a bore.
make -C curl-7.79.1
make[2]: Entering directory '/e/Rack/dep/curl-7.79.1'
Making all in lib
make[3]: Entering directory '/e/Rack/dep/curl-7.79.1/lib'
make all-am
make[4]: Entering directory '/e/Rack/dep/curl-7.79.1/lib'
CC libcurl_la-nonblock.lo
nonblock.c: In function 'curlx_nonblock':
nonblock.c:83:4: error: #error "no non-blocking method was found/used/set"
83 | # error "no non-blocking method was found/used/set"
| ^~~~~
make[4]: *** [Makefile:2531: libcurl_la-nonblock.lo] Error 1
that might be unrelated. Will try screwing around with anti-virus.
According to this [curl] build failure x86-windows-static after f12d986e6a06e0d761089d672df42511fa2dfe0d · Issue #12431 · microsoft/vcpkg · GitHub it is, indeed, an antivirus thing :S
Always exclude your dev folders from antivirus.
1 Like
Yes, I found that, too. That’s why I was hoping that’s it. And for sure recently defender has been giving me a lot of false positives on rack stuff. But I just (I think) excluded my whole rack folder, which is on a “Dev Volume”. Did rm -rf deps, git reset --hard origin, git submodule update --init --recursive, and make dep and the same thing happened.
I guess I can try one more time to do everything from scratch. Last time after I deleted my rack folder defender removed the exclusion rule I had.
$ git status On branch v2 Your branch is up to date with ‘origin/v2’.
nothing to commit, working tree clean
sigh.
trying full nuke and pave now… nope, still have problem. Guess I can try turning defender off entirely. Seems like a good time to take a vacation from VCV…
no kidding.
I hope you managed to get it working.
After trying absolutely everything to no avail, I finally rolled back the compiler using your instructions. Now deps are happily building, so I think I’ll be ok. (later: yep, vcv, deps, and fundamental plugins all good!)
Tx again!!
3 Likes
What is the lesson from this? Should we not update MSYS? Why did you update it?
Of course I do not build rack, just my plugin. Nevertheless, I’m afraid to change anything these days. At my age, I feel that I am one step away from doing something that breaks my local Win11 development environment and process and I don’t have it in me to figure out how to recover.
I suggest running a dev environment in a virtual machine - easy to snapshot and roll back to snapshot if something doesn’t work.
VMWare workstation pro is free now. I prefer it to Oracle Virtualbox that is also free.
2 Likes
Well, I’ll ramble a little…
I update all my software all the time. I probably update my msys environment at least once a week. This may be a bad idea.
I always develop my plugins against a version of rack I build myself. I think long ago this was the only way (before SDK existed?). Now it’s not the only way, but it still has some advantages.
Based on a study of one (me), I would say that the current GCC can’t build the VCV deps. The last one couldn’t build VCV at all. I’m guessing that at some point msys will distribute a version of gcc that can build curl…
Based on this study of one, I would say if msys is working for you, don’t update. There’s probably no reason to.
3 Likes