Bear with me, first time trying to get set up to write module code, and my fluency with C/C++ toolchain stuff is rusty…
I’ve been following the tutorial steps to build VCV Rack, and got as far as ‘make dep’. I am using the MSYS x64 bash shell and I’m pretty sure I’ve got all of the git repo/submodule stuff in place. When I first tried ‘make dep’, make churned for quite a while before running into the issue.
It seems related to dep/rtmidi config, but I’m very much still getting my bearings here. Here’s the shell output:
Please let me know if it’s something obvious or where I should poke around, at least. And of course, point me to a better place if this is not the right place or way to ask! Thanks.
This is probably not it, but did you do what you were supposed to with
pacman -Su git wget make tar unzip zip mingw-w64-x86_64-gcc mingw-w64-x86_64-gdb mingw-w64-x86_64-cmake autoconf automake mingw-w64-x86_64-libtool mingw-w64-x86_64-jq python zstd
fwiw I’ve never had a problem if I start with a new msys2 setup and follow the directions. There have been times in the distant past when I went hunting around myself for some of the dependencies and hosed my whole msys2 setup…
It’s a good question… I don’t think so? I did rerun it to make sure I didn’t fat-finger anything, but pacman just reinstalled everything (nothing had been left out). I’m trying again after a ‘make dep clean’ now, just in case there was some fluke. I’ll have to follow up tomorrow, and I’ll provide details of whatever I manage to investigate. Thanks.
deps is the worst part, but it usually goes just fine. Was this a fresh install of msys2? Never had a problem in that case… And you updated everything with pacman -Syu?
Well, confusingly there are two different shortcuts to start an MSYS2 based shell after installation. As the manual states:
Install MSYS2 and launch the MinGW 64-bit shell from the Start menu, not the default MSYS shell
Sounds like you might be using the “default MSYS shell” rather than the “MinGW 64-bit shell”. If I were you I would try again, following that manual to the letter, if you haven’t already.
I thought that might be the case, too, but look at that command prompt. It says MINGW64. That sounds 64 to me. I just checked and the 32 bit shell prompt is MINGW32
# working directory is root of Rack source tree
cd Rack
#get the latest from git
git pull
git submodule update --recursive --init
# clean up dependencies, by running make, target "clean" in /dep/Makefile
make -C dep clean
#clean up after previous build by running make, target "clean" in ./Makefile
make clean
#build dependencies (with ASIO, windows only)
RTAUDIO_ASIO=1 make dep
#build
make
This is a fresh MSYS install, and I’m quite sure I’ve been using the 64-bit shell (the Start window shortcut is called “MSYS2 MinGW x64” in my install).
That said, I am going try with @Jens.Peter.Nielsen’s make clean example (ignoring the RTAUDIO_ASIO definition for now, but let me know if that’s at all likely to be related to my issue).
When I first saw this issue, I did poke around a bit with the “you should run autoupdate” recommendation in the error output – didn’t get too far with it before deciding to start from scratch, but I’m happy dig deeper on that if it comes up again. I might also just try starting over really from scratch (i.e. un/re-installing MSYS and everything), just to make sure I didn’t mess something up there.
It looks like the same result after the cleanup, except for one minor difference in the warnings that were output:
In my snippet at the top of this thread, there was a warning that the AC_HEADER_STDC macro was obsolete; that warning no longer appears (and running dep/rtmidi/autoupdate results in no changes to configure.ac).
But the LIBTOOL / LT_INIT issue persists, and that seems to be where things finally choke.
I’m not familiar enough with how the library/autotools/build stuff works to do more than poke around at this stage, but I did verify that LT_INIT appears in dep/rtmidi/configure.ac (l.79, and git blame tells me that’s been unchanged for 8 years). The error message says to “make sure its definition is in aclocal’s search path,” but I have only a vague sense of what that means. Something to do with a declaration in aclocal.m4? My dep/rtmidi/aclocal.m4 does have the line:
[AC_BEFORE([$0], [LT_INIT])dnl
…but I’m not certain I’m looking for the right thing in the right place. Am I even right to assume this is an issue the rtmidi dependency? Probably something to do with build configuration, maybe something about my system getting in the way? Brainstorming…
At a bit of a loss as to what to try next, but I will keep prodding and report if anything seems interesting or enlightening. Any suggestions for fixing or troubleshooting are welcome!
I really have no idea. But maybe try running some of the utilities that you installed with pacman, and make sure they run? It’s a long shot, I admit. Here’s what I get:
bruce@DESKTOP-Q45DVE8 MINGW64 ~
$ libtool --version
libtool (GNU libtool) 2.4.6
Written by Gordon Matzigkeit, 1996
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
bruce@DESKTOP-Q45DVE8 MINGW64 ~
$ autoconf --version
autoconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
bruce@DESKTOP-Q45DVE8 MINGW64 ~
$ automake --version
automake (GNU automake) 1.16.5
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv2+: GNU GPL version 2 or later <https://gnu.org/licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by Tom Tromey <tromey@redhat.com>
and Alexandre Duret-Lutz <adl@gnu.org>.
bruce@DESKTOP-Q45DVE8 MINGW64 ~
$ gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Aha! Everything except libtool works fine, as yours. No executable libtool is not in my path, it seems. I do have some locallibtools, but not in rtmidi:
If you don’t mind @Squinky, what do you get from a which libtool?
pacman resolves the libtool package named in the instructions to a different name. That doesn’t seem problematic, but maybe something else is going wrong with setup of that util.
well, a) I don’t know if you really need that (just guessing), b) I don’t know where I got mine. I do see there are ppl out there asking about it, but I really don’t know, and don’t particularly want you to mess up your msys2 environment. dll - libtool wrapper fails silently on MSYS2 - Stack Overflow
Well, whether I messed up my environment or not (and I’m hopefully savvy enough with pacman etc to fix it if I did), I was able to resolve the issue for now. Prompted by the one answer under that SO post, I ran
$ pacman -S libtool
…which installed two different packages (not mingw-w64-x86_64-libtool or -libltdl):
After that, I was able to complete make dep and make AND make run!
I’m not sure if this was the best fix or whether it’s something that needs to get flowed back into the instructions, but do let me know if there’s a better/cleaner way or anything else that I might want to know as I dive into the module dev process. Thanks again, everyone.
Well, I would take a victory like that and not worry about it ;-). Later you can always get ambitious and install the vcv tool chain in a Linux vm, but it sounds like you are good now.
I had the same problem. Make sure your libtool dependency is updated, as well as any other tools that fail and cause errors. You can update them using a pacman command from their respective websites.
It certainly is possible that pacman made a change to its package archive, and that now, instead of installing mingw-w64-x86_64-libtool like the instructions say, you now need to install libtool instead, like I understand you did.
Yeah I can also confirm, if anyone can update the Pacman directive under windows section of the tutorial it works if you add libtool but the specified package dependencies failout on make dep without it.
I just ran pacman -Su libtool and make dep then passes.
No such issue with the toolchain docker image, but nice to have a local Win build environment
