0

你好，

我最近遇到了一个我无法解释的链接问题。

这是一个非常简单的示例：

sc_main.cpp：

#include <systemc.h>

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

我使用以下内容进行编译和链接，使用 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

现在，因为我的目标是 Win64，并且因为我想制作一个不依赖于 MinGW-64 运行时库的可执行文件，所以我一直在研究许多可能的设置：

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

在这一点上，有时它可以工作，有时它不会，这取决于我使用的 SystemC 版本：

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'

但

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

 

请注意，我使用的工具链基于 gcc 10.2.0，但这不相关。我只使用了这个工具链，因为它基于最新的 MinGW 库（8.0.0）

事实上，我已经基于相同的 MinGW 8.0.0 库和 gcc 6.3.0 生成了我自己的（交叉编译）工具链（在 linux 上运行），我看到了完全相同的结果。

知道发生了什么吗？我做错什么了吗？我不太确定这个问题是否与 SystemC 或 GCC/winpthreads 有关，但我很想认为 SystemC 可以被免除。那么谁应该受到责备，是否有解决方法？

4

1 回答 1

0

仅当使用基于 flow为 Windows 交叉编译 SystemC 库时，才会观察到configureOP 中报告的行为。

当 SystemC 库使用基于流程进行交叉编译cmake时，或者当它们在 Windows 上本地编译时，一切都会按预期工作。

SytemC 2.3.2 和 2.3.3 之间的不同行为可以通过以下事实来解释：2.3.2 不包含<pthread.h>（但依赖于 Windows 信号量），而 2.3.3 包含（通过包含）暴露了此处<mutex>提到的问题。

于 2021-09-17T18:42:47.263 回答