Jump to content


  • Posts

  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

DavidC's Achievements


Member (1/2)



  1. All right, as always devil is in the details. 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: 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.....
  2. 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
  • Create New...