This compiles fine in Visual Studio 2019 in a blank project without having to link anything or set additional include paths, but when I try to compile with g++, it fails with the following:
C:\Users\Admin\AppData\Local\HexLoader>g++ impl.cpp -o new.exe
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Admin\AppData\Local\Temp\ccfaepkX.o:impl.cpp:(.text+0x9af): undefined reference to `__imp_CoInitialize'
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Admin\AppData\Local\Temp\ccfaepkX.o:impl.cpp:(.text+0x9e5): undefined reference to `__imp_CoCreateInstance'
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Admin\AppData\Local\Temp\ccfaepkX.o:impl.cpp:(.rdata$.refptr.IID_IPersistFile[.refptr.IID_IPersistFile]+0x0): undefined reference to `IID_IPersistFile'
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: C:\Users\Admin\AppData\Local\Temp\ccfaepkX.o:impl.cpp:(.rdata$.refptr.IID_IShellLinkA[.refptr.IID_IShellLinkA]+0x0): undefined reference to `IID_IShellLinkA'
collect2.exe: error: ld returned 1 exit status
I haven't used gcc/g++ very much. I read that the functions it can't find are defined in Ole32.lib, part of the Windows SDK, so I tried:
The -L option only tells the linker where to look.
You also need to use the -l option to state which library you want to actually reference.
As a guess, you might try -lole32
The GNU linker has some implied naming rules when on Linux, I don't know how those are implemented on Windows, so there might be a bit of fussing to get the syntax right.
You should also examine the build log of your VS build to see if further libraries are also required.
C:/ProgramData/mingw64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: new.exe:.retplne: section below image base
..but if I remove the search directory and just specify the libs:
g++ impl.cpp -o new.exe -lole32 -luuid
..it compiles.
My program generates data.h and impl.cpp in app data, and compiles a new bin with g++. It's a pretty lightweight application (and already needs to autoinstall chocolatey with PowerShell, then autoinstall MinGW with chocolatey) so I don't want the end user to have to download Win SDK as well. I'm thinking I'll just store the two lib files as resources, and write them to the app data folder before compilation.
When using GCC from MinGW (or mingw-w64), you should not use the -L option to add the Windows SDK "Lib" directory. That is because MinGW (or mingw-w64) already comes with its own import libraries and header files for the Win32 API! If you use -L option to add the Windows SDK "Lib" directory, then GCC will now link the import libraries from the Windows SDK, rather than linkingit its own ones – but it will still be using the MinGW-provided header files for compilation, because you haven't used the -I option! Of course, you could use option -I to force GCC to use the header files from the Windows SDK "Include" directory, in order to at least be consistent – but that may cause other problems. So, just use the header files and the import libraries that come with MinGW (or mingw-w64) and that's it 😏
The import libraries for the WinAPI are different for each compiler, a different format. It is recommended you use GCC libs for GCC/G++ and the WinAPI libs for MSVC.
GCC/MinGW links different machine code than what MSVC links even though it theoretically performs the same function(s).