编译个qtcreator来测试一下吧[邪恶的笑容]。
能不能编译终极解码器视频软件?
啊等下……分享一下咋搞的?
昨天试了试pcxs2,这玩意是qt6的。
现在有个问题是,这个qt仍然是用glibc++编译的,而很多qt6项目用到了c++20的特性,只能用完整clang工具链编译,但qt不允许混合基础库,不能一个用libc++,一个用glibc++
也就是说,可能需要用libc++再编译一套qt以适用某些项目。
我不懂c++,不知道理解的对不对。
直接在qt官网下载qt6.5的包也是可以运行的吧。专业版glibc2.28是满足运行条件的。
我在试,不过另一个问题是,一旦项目用到了qt6,那么大概率项目的很多依赖都超出了debian10提供的范畴,这就要不停的编译依赖,而依赖往往也有自己的依赖,就陷入一层一层的编译依赖的枯燥工作中。
而结果,要么就是编译到好几层依赖时才发现有一个依赖包不可能编译到debian10上,不得不放弃
要么就是编译成功了,但所有高版本依赖统统都要一起打包,不然在纯debian10底层无法运行。而这样的结果其实还不如appimage或者玲珑这样的容器包。
总而言之一句话,这个debian10的底层是真的坑。
我在试,不过另一个问题是,一旦项目用到了qt6,那么大概率项目的很多依赖都超出了debian10提供的范畴,这就要不停的编译依赖,而依赖往往也有自己的依赖,就陷入一层一层的编译依赖的枯燥工作中。
而结果,要么就是编译到好几层依赖时才发现有一个依赖包不可能编译到debian10上,不得不放弃
要么就是编译成功了,但所有高版本依赖统统都要一起打包,不然在纯debian10底层无法运行。而这样的结果其实还不如appimage或者玲珑这样的容器包。
总而言之一句话,这个debian10的底层是真的坑。
如果是这样的话,实际上就是自己创造了一个介于debian 10 和 更新的版本 之间的独立发行版了,毕竟各种依赖版本都变了
那也许更好的方案还是更新的容器...?
我还是比较好奇你是如何编译的qt6
是在另一个debian 10上用升级过的gcc编译的吗?
如果是这样的话,实际上就是自己创造了一个介于debian 10 和 更新的版本 之间的独立发行版了,毕竟各种依赖版本都变了
那也许更好的方案还是更新的容器...?
我还是比较好奇你是如何编译的qt6
是在另一个debian 10上用升级过的gcc编译的吗?
github上最早有个用ubuntu18编译qt6的仓库,但那个我没成功
https://github.com/techcaotri/ubuntu-18.04-build-qt6
12月又有人公布了一个新的仓库
https://github.com/AlienCowEatCake/docker-amd64-bionic-qt6projects
重点是,这个作者传了dockerhub,有x86,arm32和arm64三个架构
我只是把他们拷贝出来而已。不过我看了他的过程,就是自编译llvm,自编译libxcb,然后用clang19编译qt6并打了一些补丁。
我自己当年用clang12(第一个仓库的作法)和clang19都没成功过。
===============================================================
试了几个qt6项目,包括你说的那个qbittorrent
现在的问题是,如果用glibc的基础库(clang的默认行为),因为调用的glibc过低,缺少很多特性编译不过去
如果用llvm的基础库libc++,倒是能编译到100%,但是链接时会报错,也就是说,除非把所有链接库都改成libc++的基础,不然混合链接两种基础库是会报错的。
这个不知道怎么解决。看来只能编译一些虽然用了qt6,但没有用高级c++特性的项目。
github上最早有个用ubuntu18编译qt6的仓库,但那个我没成功
https://github.com/techcaotri/ubuntu-18.04-build-qt6
12月又有人公布了一个新的仓库
https://github.com/AlienCowEatCake/docker-amd64-bionic-qt6projects
重点是,这个作者传了dockerhub,有x86,arm32和arm64三个架构
我只是把他们拷贝出来而已。不过我看了他的过程,就是自编译llvm,自编译libxcb,然后用clang19编译qt6并打了一些补丁。
我自己当年用clang12(第一个仓库的作法)和clang19都没成功过。
===============================================================
试了几个qt6项目,包括你说的那个qbittorrent
现在的问题是,如果用glibc的基础库(clang的默认行为),因为调用的glibc过低,缺少很多特性编译不过去
如果用llvm的基础库libc++,倒是能编译到100%,但是链接时会报错,也就是说,除非把所有链接库都改成libc++的基础,不然混合链接两种基础库是会报错的。
这个不知道怎么解决。看来只能编译一些虽然用了qt6,但没有用高级c++特性的项目。
如果是这样的话,可以考虑用升级过glibc的docker编译然后搭配 ablrun 使用和分发,这样能解决glibc的问题,或者也许可以直接使用ablrun启动编译来直接链接到更新版本的glibc
clang/llvm工具链我不太了解,抱歉可能给不了什么经验啦
能不能整个输入法啊,qt6下无法输入中文
Popular Events
More

中文 
众所周知debian10/ubuntu18上没有qt6,自带的gcc8也不可能编译出qt6
网上也鲜有在这俩玩意上编译qt6的先例。
过年期间终于找到了在debian10/ubuntu18跑qt6 的方法,现在可以在专业版上原生编译qt6项目了
大家有什么只有qt6的项目发来我试试看?