Link issue on Windows with pthreads - Is gcc or SystemC to blame?

Question

​ Hi,

I've recently come across a link issue that I cannot explain.

Here is an example that couldn't really be simpler:

sc_main.cpp:

#include <systemc.h>

int sc_main (int argc, char* argv[])
{
  sc_start(SC_ZERO_TIME);
  return(0);
} 

I use the following to compile and link, with winlibs-x86_64-posix-seh-gcc-10.2.0-mingw-w64-8.0.0-r7.7z:

g++ -pthread main_sc.cpp -o main_sc.exe -s $(LDFLAGS) -I$(SYSTEMC_HOME)/include -L$(SYSTEMC_HOME)/lib-mingw64 -lsystemc

Now, because I'm targeting Win64, and because I want to make an executable without any dependence on MinGW-64 run-time libraries, there are a number of possible settings that I've been looking at:

Option 1 - LDFLAGS := -static
Option 2 - LDFLAGS := -static-libgcc -static-libstdc++ -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic
Option 3 - LDFLAGS := -static-libgcc -static-libstdc++ -Wl,-Bstatic,--whole-archive -lpthread -Wl,-Bdynamic -Wl,--no-whole-archive

At this point, sometimes it works, sometimes it doesn't, depending on the SystemC release I'm using:

SytemC 2.3.2 + Option 1 : fine
SytemC 2.3.3 + Option 1 : libsystemc.a(sc_prim_channel.o):sc_prim_channel.cpp:(.text+0x44): undefined reference to `__imp_pthread_mutex_unlock'
                          libsystemc.a(sc_prim_channel.o):sc_prim_channel.cpp:(.text$_ZN7sc_core13sc_host_mutex6unlockEv[_ZN7sc_core13sc_host_mutex6unlockEv]+0xa): undefined reference to `__imp_pthread_mutex_unlock'
                          libsystemc.a(sc_prim_channel.o):sc_prim_channel.cpp:(.text$_ZN7sc_core17sc_host_semaphore7trywaitEv[_ZN7sc_core17sc_host_semaphore7trywaitEv]+0x2f): undefined reference to `__imp_pthread_mutex_unlock'

but

SytemC 2.3.2 + Option 2 or 3 : fine
SytemC 2.3.3 + Option 2 or 3 : libpthread.dll.a(d000077.o):(.text+0x0): multiple definition of `pthread_mutex_unlock' ; mingw-w64-v8.0.0/mingw-w64-libraries/winpthreads/src/mutex.c:207: first defined here

 

Note that I the toolchain I am using is based on gcc 10.2.0 but that's not relevant. I only used this toolchain because it's based on the latest MinGW libraries (8.0.0)

In fact, I have generated my own (cross-compilation) toolchain (running on linux), based on the same MinGW 8.0.0 libraries and on gcc 6.3.0 and I'm seeing the exact same results.

Any idea what's going on ? Am I doing anything wrong ? I'm not too sure if the issue has to do with SystemC or with GCC/winpthreads, but I'm tempted to think that SystemC can be exonerated. So who's to blame, and is there a workaround ?

Answer 1

The behavior reported in the OP is only observed when SystemC libraries are cross-compiled for Windows, using the configure based flow.

When the SystemC libraries are cross-compiled using the cmake based flow, or when they are natively compiled on Windows, then everything works as expected.

The different behavior between SytemC 2.3.2 and 2.3.3 is explained by the fact that 2.3.2 does not include <pthread.h> (but relies on Windows Semaphore), whereas 2.3.3 does (via the inclusion of <mutex>) which exposes the issue mentioned here.