I've observed some issues when cross-compiling SystemC 2.3.3 libraries for Windows (on a linux machine).
The first cosmetic obstacle is that src\sysc\kernel\sc_cmnhdr.h has the following:
# include <Windows.h>
This is absolutely fine when natively building on Windows, but linux is case sensitive and isn't too happy about this.
A simple change to
# include <windows.h>
is enough to fix the problem.
More generally though, this tells me that cross-compiling SystemC libraries hasn't really been tested or verified, correct ?
The next observation I would like to share is that the CMake-based and the autoconf-based flow do not exactly produce the same build configuration, which ultimately leads to different behaviors.
Essentially in a few words, the autoconf-based flow generates Makefile recipes that define DLL_EXPORT when compiling the SystemC source files.
On the contrary, the CMake-based flow generates Makefile recipes that do not define DLL_EXPORT.
This is an important aspect because there is an interaction with the toolchain header files, that do check for DLL_EXPORT, and adjust their behavior accordingly. Ultimately this is the difference between a success and a failure at link time.
So which SystemC build configuration is correct ?
At first sight, this might seem like a moot point, because there is not a single reference to DLL_EXPORT in the SystemC source code. However there might be other tools involved in the whole build process that somehow check for DLL_EXPORT, but only the maintainers of SystemC can confirm that.
Note that there might also be a potential issue in the toolchain header files (MinGW-w64), that incorrectly react to DLL_EXPORT being defined or not, I'm too sure.
Any experts comments on this ?
For the interested reader, you will find all the details and necessary steps to reproduce the issue here: https://stackoverflow.com/questions/69171109/cross-compiling-systemc-libraries-and-linking-to-them/