Linker error building locally on Windows

[SteveRussell33]

[100%] Linking CXX shared module plugin.dll
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8SHEVInfoEE6setLEDILNS1_4ElemE45ENS_11FullColor_tEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8SHEVInfoEE6setLEDILNS1_4ElemE46ENS_11FullColor_tEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE10ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE11ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE13ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE15ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE7ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE8ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZN10MetaModule18SmartCoreProcessorINS_8TapoInfoEE6setLEDILNS1_4ElemE9ESt5arrayIbLy3EEEEvRKT0_: symbol wrong type (4 vs 3)
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/14.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot export _ZStssIjjENSt8__detail18__cmp3way_res_implIT_T0_E4typeERKSt8optionalIS2_ERKS3_: symbol wrong type (4 vs 3)
collect2.exe: error: ld returned 1 exit status
make[3]: *** [CMakeFiles/plugin.dir/build.make:1146: plugin.dll] Error 1
make[2]: *** [CMakeFiles/Makefile2:231: CMakeFiles/plugin.dir/all] Error 2
make[1]: *** [Makefile:156: all] Error 2
make[1]: Leaving directory '/c/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/build'
make: *** [Makefile:35: build/plugin.dll] Error 2

[danngreen]

Hmm, might be related to this bug: https://stackoverflow.com/questions/28267100/dll-linking-failed-with-lto-using-mingw-w64

I'll try to start up my windows VM and see if I get the same error. If so, I'll see if adding the -fno-use-linker-plugin flag helps. And/or removing LTO

[danngreen]

Ok, linking failed for me (but with a different error) on msys2. Removing LTO from the build fixed it. It's not needed anyways for host computer use (only when built for MetaModule hardware).

I pushed the fix to the main branch. Could you try again and let me know?

[SteveRussell33]

Hi Dan, OK the build is now fixed, thanks for that, but the plugin won't load into VCV. I even tried the build from the CI Releases page. Relevant line from the log:

[11.606 warn src/plugin.cpp:196 loadPlugin] Could not load plugin ./plugins-win-x64/4msCompany: Failed to load library ./plugins-win-x64/4msCompany/plugin.dll: code 127

[danngreen]

Thanks. Hmm, code 127... I found this: https://community.vcvrack.com/t/code-127/14863/5

though, that wouldn't explain why the CI Release didn't work for you.

What Rack version are you using? Also, what is the gcc toolchain version you're using?

For reference, I just tried building it using mingw64 gcc 13.2, on a Windows 11 VM, and it loaded and ran in Rack 2.5.2. Also the CI Release worked on the same system.

[SteveRussell33]

Msys2/mingw64 GCC 14.2.0, Windows 10, Rack 2.5.0 (self-build therefore my plugin builds are using source not the SDK, yet to do 2.5.2 update)

[danngreen]

OK. I'll try to replicate it here.

Could you try installing a pre-built Rack and see if the Release 0.18.0 works for you? And if so, if a clean build of the plugin works on a pre-built Rack?

The 4ms plugin works with Rack v2.4.1 as well, in case you already have that installed.

[danngreen]

Aha! I tried loading the Release into Rack 2.5.0. I get the same code 127 error that you saw. So I suspect it's something that got fixed between Rack 2.5.0 and 2.5.2. I'll look into the git diff and see if I can spot it

[danngreen]

Nothing obvious in the git log for Rack.

I attached a debugger when loading the plugin under Rack 2.5.0, and we get this missing symbol (demangled): std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_replace_cold(char*, unsigned long long, char const*, unsigned long long, unsigned long long)

So clearly that symbol is supposed to be in libstdc++, which is supposed to be linked statically.

[danngreen]

Ok, I might be getting to the bottom of this. Rack v2.5.2 introduces this change in the Makefile:

cp /mingw64/bin/libstdc++-6.dll $(DIST_DIR)/

Which would explain why 2.5.2 finds that libstdc++ symbol and 2.5.0 doesn't.

If I add the -static-libstdc++ flag to the plugin build for msys2/mingw then it loads in Rack v2.5.0 and in v2.5.2

I just pushed the fix. When you get a chance, will you try to build again and test on your self-built Rack 2.5.0?

[danngreen]

Release 0.19.0 contains the fix. I manually tested on mac, linux, and windows with both 2.5.0 and 2.5.2.

[SteveRussell33]

Good work Dan! Updated to latest commit with clean repo - successful build. Plugin loaded with my Rack 2.5.0 as did the latest build from CI.

Could you detail what command(s) you used in post https://github.com/4ms/4ms-vcv/issues/3#issuecomment-2293863399 as I use GDB to find where SEG faults occur using my DEBUG build of Rack loading the plugin in question and would be interested in your process here for reference.

Of note (forgot to mention this last time) the build is somewhat noisy with -Wunused-variable warnings. For the one shown I would remove #include <rack.hpp> from src/mapping/midi_modules.cc as it's already declared in src/mapping/midi_modules.hh and src/mapping/module_directory.hh (Edit: PR added)

[ 68%] Linking CXX static library libCoreModules-4ms.a
[ 68%] Built target CoreModules-4ms
[ 69%] Building CXX object CMakeFiles/plugin[. d6i9r%/]s rBc[u/ ic7lo0dm%im]n/ gc oBCmuXmiX_l mdooibdnjugel ceCt.X cXCc M.oaobkbjejeF
citl eCs[M/ ap7kl0eu%Fg]ii lne.Bsdu/iiprll/dusigrnicgn/ .hCduXibXr/ /hosubrbjc_e/mchatup b_C/bhMuuatbkt_eomFnei.dlciecus.m/o.pbcljcu
.goibnj.
dir/src/mapping/midi_modules.cc.obj
In file included from C:/_Projects/VCVRack/V2/Rack/include/rack.hpp:26,
                 from C:/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/src/comm/comm_jack.hh:3,
                 from C:/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/src/comm/comm_module.hh:3,
                 from C:/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/src/comm/comm_module.cc:1:
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp: In constructor 'rack::SharedMutex::SharedMutex()':
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:20:21: warning: unused variable 'err' [-Wunused-variable]
   20 |                 int err = pthread_rwlock_init(&rwlock, NULL);
      |                     ^~~
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp: In member function 'void rack::SharedMutex::lock()':
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:28:21: warning: unused variable 'err' [-Wunused-variable]
   28 |                 int err = pthread_rwlock_wrlock(&rwlock);
      |                     ^~~
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:In file included from  In member function 'C:/_Projects/VCVRack/V2/Rack/include/rack.hpp:26void rack::SharedMutex::,
                 from unlockC:/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/src/mapping/midi_modules.hh:3(),
                 from ':
C:/_Projects/VCVRack/V2/Rack/plugins/4ms-vcv/src/mapping/midi_modules.cc:1C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:36:21::
 C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:warning:  In constructor '                 rack::SharedMutex::   SharedMutex   ()-Wunused-variable':
]
   36 |                 int C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:20:21:err  = pthread_rwlock_unlock(&rwlock);
      |                              ^~~
errC:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:' [ In member function '-Wunused-variablevoid rack::SharedMutex::]
                            lock_sharederr() = pthread_rwlock_init(&rwlock, NULL);
      |                     ':
^~~C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:41:21:
 C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:warning:  In member function 'unused variable 'void rack::SharedMutex::errlock' [()                 ':
]
                            C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:28:21:     = pthread_rwlock_rdlock(&rwlock);
      |                     warning: ^~~unused variable '
err' [-Wunused-variable]
   28 |                 int err = pthread_rwlock_wrlock(&rwlock);
      |                     ^~~
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp: In member function 'void rack::SharedMutex::unlock()':
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:36:21: warning: unused variable 'err' [-Wunused-variable]
   36 |                 int err = pthread_rwlock_unlock(&rwlock);
      |                     ^~~
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp: In member function 'void rack::SharedMutex::lock_shared()':
C:/_Projects/VCVRack/V2/Rack/include/mutex.hpp:41:21: warning: unused variable 'err' [-Wunused-variable]
   41 |                 int err = pthread_rwlock_rdlock(&rwlock);
      |                     ^~~

[danngreen]

Good work Dan! Updated to latest commit with clean repo - successful build. Plugin loaded with my Rack 2.5.0 as did the latest build from CI.

Excellent!

Could you detail what command(s) you used in post #3 (comment) as I use GDB to find where SEG faults occur using my DEBUG version of Rack loading the plugin in question and would be interested in your process here for reference.

I usually use gdb as well (or lldb on macos), but I do very little dev on windows, so I had to look it up. I ended up first installing the "Debugging Tools for Windows", using their standalone installer and unchecking everything except the Debug Tools: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

Then from the Windows shell (not MSYS) I ran gflags -i C:\...\Rack.exe +sls from the debug tools dir, as described here: https://stackoverflow.com/questions/1053180/loadlibrary-error-code-127

Finally, I ran the GUI debugger tool that the Debug Tools installed (sorry, I don't have that VM running, but it was called something like "Windows Debug"). From there I launched Rack. Scrolling through the console, I was able to spot the part where the dll fails to load, and the error message.

Of note (forgot to mention this last time) the build is somewhat noisy with -Wunused-variable warnings. For the one shown I would remove #include <rack.hpp> from src/mapping/midi_modules.cc as it's already declared in src/mapping/midi_modules.hh

We can definitely remove the extra #include <rack.hpp> in midi_modules, I see your PR for that.

Though I don't see any of those warnings in any of my local builds or in the CI builds.

The warnings all appear to be in Rack header files, and it looks like they were addressed in the Rack repo somewhere between 2.5.1 and 2.5.2 (commit befbb0). So I'm not sure if there's anything we could do here, except add a compiler flag to silence them (which is probably not a good idea, and it's already fixed upstream anyways).

I do have two warnings when I build a Release build on macOS only, and they're from the rapidyaml library (in error.cpp). I will upgrade that library eventually since it's been fixed upstream.

[SteveRussell33]

I usually use gdb as well (or lldb on macos), but I do very little dev on windows, so I had to look it up. I ended up first installing the "Debugging Tools for Windows", using their standalone installer and unchecking everything except the Debug Tools: https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/debugger-download-tools

Then from the Windows shell (not MSYS) I ran gflags -i C:\...\Rack.exe +sls from the debug tools dir, as described here: https://stackoverflow.com/questions/1053180/loadlibrary-error-code-127

Finally, I ran the GUI debugger tool that the Debug Tools installed (sorry, I don't have that VM running, but it was called something like "Windows Debug"). From there I launched Rack. Scrolling through the console, I was able to spot the part where the dll fails to load, and the error message.

Thanks for that - noted for next time I get that error

The warnings all appear to be in Rack header files, and it looks like they were addressed in the Rack repo somewhere between 2.5.1 and 2.5.2 (commit befbb0). So I'm not sure if there's anything we could do here, except add a compiler flag to silence them (which is probably not a good idea, and it's already fixed upstream anyways).

Ah yes I see it now - as I said previously not done the 2.5.0 -> 2.5.2 delta yet.

Thanks for the help, much appreciated. Have a good weekend!

I'll let you close this issue if you have anything to add.

[danngreen]

Thanks for the help finding those issues!