Jump to content

Cross-compiling SystemC for windows


Recommended Posts


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/





Link to comment
Share on other sites

All right, as always devil is in the details.


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

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:


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.....

Link to comment
Share on other sites

  • 3 months later...

@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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Create New...