Okay that project is rather huge. I’ve stripped the problem to first testing whether PlatformIO + GCC are able to link with VisualStudio-built libraries at all. So I created a new static library in VisualStudio with very simple code
#ifndef VSSTATIC_LIB_H
#define VSSTATIC_LIB_H
class VSStaticLibClass {
public:
void TestFunc();
};
#endif //VSSTATIC_LIB_H
#include "VSStaticLib.h"
#include <stdio.h>
void VSStaticLibClass::TestFunc() {
printf("VSStaticLibClass::TestFunc() was reached :)\n");
}
and built it in release mode to get a VSStaticLib.lib.
Created a new blank PlatformIO project, created the folder lib/VSStaticLibTest (important to not call it VSStaticLib because then there is a name conflict with the library file libVSStaticLib.a file that PlatformIO auto-generates, even when only headers and no implementation code is present, unless lib_archive=no), put the VSStaticLib.h and VSStaticLib.lib file inside it and wrote my platformio.ini is
[env:native]
platform = native
build_flags =
-L lib/VSStaticLibTest
-lVSStaticLib
with code
#include <stdio.h>
#include <VSStaticLib.h>
int main() {
printf("Hello, world!\n");
VSStaticLibClass test;
test.TestFunc();
return 0;
}
and building it gives…
C:\Users\Max\Downloads\VS_PIO>pio run
Processing native (platform: native)
------------------------------------------------------------------------------------------------------------------------
Verbose mode can be enabled via `-v, --verbose` option
LDF: Library Dependency Finder -> http://bit.ly/configure-pio-ldf
LDF Modes: Finder ~ chain, Compatibility ~ soft
Found 1 compatible libraries
Scanning dependencies...
Dependency Graph
|-- <VSStaticLibTest>
Building in release mode
Compiling .pio\build\native\src\main.o
Archiving .pio\build\native\libc40\libVSStaticLibTest.a
Indexing .pio\build\native\libc40\libVSStaticLibTest.a
Linking .pio\build\native\program.exe
c:/program files/mingw-w64/x86_64-8.1.0-posix-seh-rt_v6-rev0/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: .pio\build\native\src\main.o:main.cpp:(.text+0x21): undefined reference to `VSStaticLibClass::TestFunc()'
collect2.exe: error: ld returned 1 exit status
*** [.pio\build\native\program.exe] Error 1
=================[FAILED] Took 1.11 seconds =================[
This goes to show that there is a general problem indeed with mixing MinGW and VS libraries in the most simple example, as I have previously suspected. With this simple case not working, it doesn’t yet make sense to try this in the giga-size project.
You can also see from e.g. other projects, such as libSDL, that they have separate VC (Visual C in this case) and MinGW development libraries for Windows.
I’ll investage on whether Lib2A helps in this simple case, whether other conversion tools are available or whether I can find more info on why GCC can’t handle VS libs. I’ve already found this that states a VisualSudio compile setting may influence it.
On another note it might be possible to recompile the Gazebo libraries either on Windows with a MinGW toolchain instead of VisualStudio, however even they say that
At this moment, compilation has been tested on Windows 8.1 and 10, supported when using Visual Studio 2017. Patches for other versions are welcome.
may not be possible. However, another possible trick is compiling it on Linux using this, but exchanging the compiler from GCC to x86_64-w64-mingw32-gcc, aka cross-compiling from Linux for Windows (MinGW).
But, one thing at a time.
EDIT: Another thought I just had that the problem could lie with C++ mangling names – The MSVC compiler encodes class names and functions differently than GCC, see https://demangler.com/, so maybe GCC can’t find the function because it expects a different name.