我琢磨引入的日志库和qt在xp下有冲突，引入之前好好的。
loguru简单点就一个文件，简单排除了下，可以最小化重现：

#include "mainwindow.h"
#include <QApplication>

char* get_thread_name_win32()
{
    __declspec( thread ) static char thread_name[1] = {0};
    return thread_name;
}

int main(int argc, char *argv[])
{
    QApplication a(argc, argv);

    MainWindow w;
    w.resize(800, 600);
    w.show();
    return a.exec();
}

什么都没干，只是定义了那个函数。
看着是和TLS有关系，但搜了下spdlog，居然没找到__declspec( thread )。。。
又搜了下，果然有，用的thread_local。

【 在 hgoldfish 的大作中提到: 】
: 从这行代码看，是不是 vc2017 对 atomic 的支持有 xp 上面有问题？
: 查了一下代码，在 configure 的时候加上这个定义看看？
: QT_ATOMIC_FORCE_NO_CXX11
: ...................
--
修改:cn62 FROM 175.42.42.*
FROM 175.42.42.*

spdlog加上SPDLOG_NO_TLS就可以了。
就是说TLS废掉了，应用的代码都不能用TLS。

【 在 cn62 的大作中提到: 】
: 我琢磨引入的日志库和qt在xp下有冲突，引入之前好好的。
: loguru简单点就一个文件，简单排除了下，可以最小化重现：
: #include "mainwindow.h"
: ...................
--
FROM 175.42.42.*

spdlog我没用dll，直接包含的header only文件。
qt的库也不可能用LoadLibrary。

【 在 javaboy 的大作中提到: 】
: 不用LoadLibrary，直接动态链接试试。
:
--
FROM 175.42.42.*

对的，那个qwindows是platform plugin，运行时加载的。

【 在 javaboy 的大作中提到: 】
: 你用depends之类的工具看看exe是否直接依赖那个dll。是的话tls应该没问题的。
:
--
FROM 175.42.42.*

不是。和vc2017没关系。和qt有部分关系。

原因是windows xp的LoadLibrary不会正确处理TLS entry，会导致threadlocal数据未初始化。qt一定要用tls，就会在xp上引起bad access。

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 估计是 vc2017 哪里有问题。查了一下 qt 5.6 是 2016 年发布的，那会儿没对 vc2017 仔细测试过吧。
--
FROM 114.84.103.*