回复: mingw编译问题，好多年一直存在?
#6 回 fsu0413 的帖子 [adonais 04-25 13:53]
fsu0413:看了下生成的makefile里没有qmutex_win.cpp的编译，不知道原理
推测可能是qmake耦合了这块地方，但是我没有去调查，楼主如果感兴趣的话可以调查一下 (2020-04-20 22:45)
做了个测试,
q1.pro如下:
TEMPLATE = app
TARGET = q1
INCLUDEPATH += .
CONFIG -= qt debug_and_release
CONFIG += console
SOURCES += 1.c 2.c 3.c
=======================
1.c:
#include
#include "2.c"
extern void bar(void);
int main(void) { foo(); bar(); return 0; }
2.c:
void foo(void) { printf("foo printf\n"); }
3.c
#include
void bar(void) { printf("bar printf\n"); }
运行qmake，生成的Makefile确实不包括2.o
那么之所以出现我描述的情况，应该是使用configure时mingw预编译出来的qmake有问题.
#7 回 adonais 的帖子 [fsu0413 05-12 22:10]
adonais:做了个测试,
q1.pro如下:
TEMPLATE = app
TARGET = q1
....... (2020-04-25 13:53)
你用的mingw是哪个版本的？我这边的7.3.0没这个问题
#8 回 fsu0413 的帖子 [adonais 05-15 00:27]
fsu0413:你用的mingw是哪个版本的？我这边的7.3.0没这个问题 (2020-05-12 22:10)
https://sourceforge.net/projects/libportable/files/Tools/gcc-win64-9.3.1.7z
不关mingw版本的事。
既然定位到是预编译qmake的问题，把事情搞清楚就不难了
对比了一下预编译qmake和最终生成qmake之间的代码,发现跟环境变量相关。
我在编译qt之前，喜欢先设置INCLUDE和LIB环境变量，引入依赖库的路径(openssl.icu,mysql..).
把这些环境变量取消掉，生成的Makefile就正常了.
#9 [九重水 05-15 14:24]
神一般的用法，还没#include 过XXX.cpp文件；
一般#include xxx.h文件，然后在.h文件里面用#ifndef YYYY_H ……
所以没遇到过这么神奇的事情。
#10 回 adonais 的帖子 [fsu0413 05-18 08:32]
adonais:https://sourceforge.net/projects/libportable/files/Tools/gcc-win64-9.3.1.7z
不关mingw版本的事。
既然定位到是预编译qmake的问题，把事情搞清楚就不难了
....... (2020-05-15 00:27)
加include路径和lib可以用configure自带的命令啊。。。。动环境变量可能牵一发动全身