这是一个创建于 1928 天前的主题，其中的信息可能已经有所发展或是发生改变。
假如我再 windows 上面写的 qt 程序编译器是 msvc2015，然后把代码拷贝到 ubuntu 环境，在 ubuntu 环境下用 qt 编译，编译器要和 windows 的 qt 一样吗？？？
 |
1
ipwx 2019-08-24 10:55:24 +08:00 via Android
用 gcc 啊，送分题，下一问
|
 |
2
deorth 2019-08-24 11:16:55 +08:00
windows 用 mingw
|
 |
3
firemiles 2019-08-24 12:02:06 +08:00
没楼主 linux 下装个 qt 玩下就知道了
|
 |
4
hsuehsen 2019-08-24 12:58:26 +08:00
不同平台，用各自平台的编译器编译就可以
|
 |
5
cjw6 2019-08-24 13:04:15 +08:00 via Android
不要用各自平台的 api，用 qt 的 api，c++跨平台特性，可以直接跨平台编译
|
 |
6
xiri 2019-08-24 13:57:59 +08:00
ubuntu 下肯定用 gcc 啊
qt 是跨平台的，api 都是通用的，代码不需要动，装好 linux 版的 qt 直接编译就行了 不过有一些组件还是需要注意一下，比如 mingw 下没法使用 webengine （不记得名字对不对，反正就是 webview 相关的） |
 |
7
bayunjue 2019-08-24 14:06:56 +08:00
qmake，cmake 都可以
|
 |
8
hhyvs111 2019-08-24 14:07:30 +08:00
不能编译，坑很多
|
 |
9
zhiwoda123 OP @xiri 大佬我刚学 qt 不是很懂，我想问一下假如 win7 平台 qt 用的 msvc2015 编译器写的代码，ubuntu 上面 qt 用的 mingw 可以编译 win7 拷贝过来的代码吗
|
|
10
xiri 2019-08-24 14:24:57 +08:00 via Android
@zhiwoda123 ubuntu 下直接用 gcc 啊，mingw 是 windows 下的
至于 win 下写的代码放到 ubuntu 下编译，问题应该不是很大，qt 本来就是主打跨平台的，就算要改应该也不是啥大问题。 我用 qt 也不是很多，就自己写了一些小工具，都是换个编译器就能直接跑动的，唯一碰到的就是上面提到的有些组件 mingw 下没有点问题了 |
|
11
ipwx 2019-08-24 14:30:02 +08:00
@zhiwoda123 大部分代码没问题。少部分你可以用宏 #ifdef 控制一下。
https://blog.kowalczyk.info/article/j/guide-to-predefined-macros-in-c-compilers-gcc-clang-msvc-etc..html |
 |
15
reus 2019-08-24 15:22:32 +08:00
你自己试一下不就知道了
linux 哪来的 msvc? |
 |
16
4thirteen2one 2019-08-24 15:42:14 +08:00 via Android
这个......和编译器没关系吧......除非你有一些指定的依赖项只有 win 里面有。话说可以尝试一下 pyqt
|
 |
17
ztcaoll222 2019-08-24 17:30:28 +08:00
可以尝试用下 msys2
|
 |
18
aa514758835 2019-08-24 17:41:32 +08:00
不用吧，如果你写的代码没有依赖平台，都用 Qt 的，直接拷贝代码过去编译即可，
|
 |
19
dixeran 2019-08-24 18:27:55 +08:00 via Android
只要你用的都是 Qt 的接口，没引用 windows.h 或者调用系统相关 API，那编译器用哪个都没关系。
|
 |
20
wbing 2019-08-24 18:55:24 +08:00 via iPhone
ubuntu 下面没有 msvc2015。
只要你没用 win 下特有的 api，代码能直接编译过的。 用 msvc 编写出来的程序可以在 windows 下打开，gcc 编译出来的可以在 linux 下打开。 |
|
22
ipwx 2019-08-25 19:54:46 +08:00
@FrankHB MSVC 是 windows 下的标准。
别的程序给的 DLL/LIB 都用 MSVC 编译的，你要用，你只能用 MSVC。 再说了，微软自家的东西，当然是微软自己最清楚。我还不信任 mingw 呢。 |
 |
23
FrankHB 2019-08-25 22:38:05 +08:00
@ipwx MSVC 自己（而不是有强迫症的 MSVC 用户）有能称得上 Windows 下的标准的东西？有多少东西找得到跟实现准确匹配的文档？ ABI 都没敢全说清楚吧？
同等功能同等质量的实现，没源码比起有源码的就是残次品；都有源码的，依赖特定实现导致兼容性更差的更残废。既然已经在一部分实现上废了，能给全文档让人脑补逆向出源码也差强人意，逼用户从二进制逆向出来才能弄清楚实际干了坨什么的，就别好意思标榜靠谱了。然而讲个笑话，关于 MSVC 的一些东西，看 LLVM 的材料都可能比 MS 家的靠谱……再讲个笑话，直到近几年前升级 MSVC 还会 break ABI。还有一堆笑话，msvcrt 和 ucrt …… ，这不是常识么。 这还就只是人力可以做到的逆向。升级个编译器版本多出来一坨 ICE，没源码人肉修编译器试试？ 除了谁都做不到的，没能力折腾好就认，跟信任几毛钱关系。 还有，别家工具链不管是 conformance 还是 compatibility 很多情况就是库拙计的问题，cl 前端整个烂了那么多年，bug-to-bug compatible to MSVC 的东西，有源码看都能发现普遍更不靠谱。 |
|
24
FrankHB 2019-08-25 22:41:54 +08:00
编辑框抽风漏了。
“，这不是常识么。” → “把能填的坑填过了，或者至少评估过填坑的难度，再讨论靠谱程度。到处都有人在用又不保证你自己的和别人普遍的用例中能满足需求，这不是常识么。” |
|
25
FrankHB 2019-08-25 22:53:36 +08:00
@ipwx 还有啊，“你只能用 MSVC ”？× ——这是乐观过头了。
实际不少情况是只能用特定版本的被支持的 MSVC，直到甩掉这整坨屎。 说个实际案例吧。 几年前给人糊一坨 Pro/E 之类的插件，本来 VS2010 用得好好的，然后因为只给 lib 就要愣是要 VS2008，更可笑的是还只能用 libcmt 没法上 msvcrt ……最后一坨用 MSBuild 的 sln 还要拖一坨魔改过的 nmake，一台 2G 的穷酸开发机上同时开两个 VS 和一坨客户程序联调，那酸爽。。。 说 MSVC 是标准是吧……那这里到底是 VC2010 是标准还是 VC2008 是标准呢？用 MSBuild 是标准呢，还是 nmake 是标准呢？（现在 nuget 一过气，又可以一起纠结 vcpkg 和 conan 了……） 倒不是说不用 MSVC 就一定能避免这种问题，问题是别的替代实现真没那么多乱七八糟需要 version lock-in 的东西。 而且不管怎么说这种问题就算主要不是 MSVC 而是依赖项的发行商的问题，也实在没法认为是靠谱的表现吧。 |
Select Language