Cross-compiling SystemC for windows

[DavidC]

Hi,

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/

 

David

 

 

[DavidC]

All right, as always devil is in the details.

Quote

The CMake-based flow generates Makefile recipes that do not define DLL_EXPORT.

This is enforced by construction by the CMake scripts and config files. If you do

cd $SYSTEMC_SRC
mkdir build && cd build && x86_64-w64-mingw32.static-cmake ..

then you will get just an error:

The compilation of SystemC as a DLL on Windows is currently not supported!

So the end user has no choice but to invoke CMake with explicit settings for static libraries:

 x86_64-w64-mingw32.static-cmake .. -DBUILD_SHARED_LIBS=OFF

On the contrary I mentioned:

Quote

the autoconf-based flow generates Makefile recipes that define DLL_EXPORT

This is kinda true... or more precisely, the autoconf-based flow is more permissive and lets the end user do silly things...

When targeting Windows, there is something inconsistent in the autoconf based flow. The below:

./configure --host=x86_64-w64-mingw32.static

• will build a static library (libsystemc.a) as expected
• but it will happily do so using settings for shared libraries by default (assuming --enable-shared)

It makes the end-user believe that everything is fine... when it isn't.

Once you understand that and you explicitly specify settings that are consistent with building a static library (and aligned with the CMake flow):

./configure --host=x86_64-w64-mingw32.static --disable-shared

then everything works just fine.

I guess it would be a nice improvement to make the autoconf scripts more robust, so they just throw an error when targeting windows with default settings (assuming --enable-shared), similar to what the CMake scripts do.....

[maehne]

@DavidC: Thanks for reporting these cross-compilation issues. Indeed, cross-compiling has not been tested. We are aware of the inconsistencies between the autotools-based compilation flow vs. the CMake flow. I reported your findings to the LWG for consideration.