开始编译安装：
昌江黎族网站建设公司成都创新互联,昌江黎族网站设计制作，有大型网站制作公司丰富经验。已为昌江黎族近千家提供企业网站建设服务。企业网站搭建\外贸网站制作要多少钱，请找那个售后服务好的昌江黎族做网站的公司定做！
一、X11编译：
1.进入qt-x11-opensource-src-4.5.0源码目录。
./configure -no-openssl
在我这里必须加上-no-openssl选项，否则在make过程中，编译到ssl时会报错。出错信息为：
ssl/qsslsocket_openssl_symbols_p.h:264: error: variable or field ‘q_sk_free’
declared void
ssl/qsslsocket_openssl_symbols_p.h:264: error: ‘STACK’ was
not declared in this scope
ssl/qsslsocket_openssl_symbols_p.h:264: error:
‘a’ was not declared in this scope
ssl/qsslsocket_openssl_symbols_p.h:265: error: ‘STACK’ was not declared in this
scope
ssl/qsslsocket_openssl_symbols_p.h:265: error: ‘a’ was not declared
in this scope
……
……
默认安装路径为
/usr/local/Trolltech/Qt-4.5.0。可用--prefix 指定其他安装路径。
2. gmake
# linux下一般可直接用make代替gmake。如果要加快编译速度，就加上 -jx ，x表示最大的线程数。
3.
gmake install
二、qt-embedded-x86编译:
1.进入qt-embedded-linux-opensource-src-4.5.0-x86源码目录。
./configure -prefix
/usr/local/Trolltech/QtEmbedded-4.5.0-x86 -embedded x86 -no-openssl -qt-gfx-qvfb
-qt-kbd-qvfb -qt-mouse-qvfb
先后配置了安装目录、嵌入式架构（x86）。同时也跟X11版本一样，配置了
-no-openssl，没有这一项的话，make的过程中会出现跟编译X11时一样的错误。再后面的几项是为了更好的配合qvfb，网上说如果没有这几项，安装好qt-embedded-x86后想在qvfb上调试程序时，会出现类似下面的错误：
Error opening buffer device /dev/fb0QScreenLinuxFb::connect: No such
file or directory
2. gmake
跟x11版一样
3. gamke
install
三、qt-embedded-arm:
与前面两个不同，在编译arm版本的qt-embedded前，必须确认已经安装了交叉工具链，编译过程中要生成许多arm架构的库，所以必须有arm-linux-gcc、arm-linux-g++等工具。我用的是友善提供的arm-linux-gcc-4.5.1版本。
1. 进入qt-embedded-linux-opensource-src-4.5.0-arm源码目录。
./configure -prefix
/usr/local/Trolltech/QtEmbedded-4.5.0-arm -embedded arm -no-openssl
-qt-libpng
指定了安装路径、嵌入式架构。同时也跟X11版本一样，配置了
-no-openssl，没有这一项的话，make的过程中会出现跟编译X11时一样的错误。
另外，还增加了一项，
-qt-libpng，这个选项应该是关于png相关的库，指定用qt自带的png库。如果没有这一项，我这里会出现如下错误：
image/qpnghandler.cpp: In member function 'virtual QVariant
QPngHandler::option(QImageIOHandler::ImageOption) const':
image/qpnghandler.cpp:950:35: warning: 'png_info_struct::width' is deprecated
(declared at
/opt/FriendlyARM/toolschain/4.5.1/lib/gcc/arm-none-linux-gnueabi/4.5.1/../../../../arm-none-linux-gnueabi/include/png.h:639)
image/qpnghandler.cpp:950:35: warning: 'png_info_struct::width' is deprecated
(declared at
/opt/FriendlyARM/toolschain/4.5.1/lib/gcc/arm-none-linux-gnueabi/4.5.1/../../../../arm-none-linux-gnueabi/include/png.h:639)
image/qpnghandler.cpp:950:55: warning: 'png_info_struct::height' is deprecated
(declared at
/opt/FriendlyARM/toolschain/4.5.1/lib/gcc/arm-none-linux-gnueabi/4.5.1/../../../../arm-none-linux-gnueabi/include/png.h:640)
image/qpnghandler.cpp:950:55: warning: 'png_info_struct::height' is deprecated
(declared at
/opt/FriendlyARM/toolschain/4.5.1/lib/gcc/arm-none-linux-gnueabi/4.5.1/../../../../arm-none-linux-gnueabi/include/png.h:640)
make[1]: *** [.obj/release-shared-emb-arm/qpnghandler.o] 错误 1
make[1]:
*** 正在等待未完成的任务....
make[1]: Leaving directory
`/root/qt4.5.0/qt-embedded-linux-opensource-src-4.5.0-arm/src/gui'
make:
*** [sub-gui-make_default-ordered] 错误 2
看起来像是我的交叉工具链跟这个QT版本匹配的不太好，Qt好像不太兼容交叉工具链的png.h头文件中定义的数据结构。加上 -qt-libpng
可解决此问题。
四、qvfb:
这时QT就已安装成功。但是还需要额外安装qvfb。
进入qt-x11-opensource-src-4.5.0源码包目录，然后
cd tools/qvfb
在qvfb源码目录下运行
make
会在qt-x11-opensource-src-4.5.0/bin下生成qvfb,我们将它copy至/usr/local/Trolltech/QtEmbedded-4.5.0-x86/bin下即可。
end:
到这里，QT的开发环境基本就搭建好了，利用 qt-embedded-x86 和 qvfb
工具可以很方便的调试QT程序，调试好的程序再经 qt-embedded-arm
编译就可在开发板上运行(还有个小问题，我现在编译好的QT程序虽然可以在开发板上运行，但是运行时触摸屏不能用，只能用USB鼠标控制，想支持触摸屏貌似还需要移植tslib库，等我折腾完了再回来把相关内容补充上)。
刚看到中国首个桌面操作系统开发者平台“开放麒麟”发布了，新闻稿表示将打造具有自主创新技术的开源桌面操作系统，通过开放操作系统源代码的方式，让开发者共同参与国产开源操作系统的开发。[献花花]
问了几个技术领域朋友。有朋友说，看到国家来主推自有桌面操作系统挺振奋，但官网社区首先推出自有的开源 UI 库UKUI，感觉还是没有放到自主和生态方面去考虑，因为推出的 UKUI 是采用 QT 来开发的，QT 虽然有社区免费版，但如果使用的话，基于 QT 的软件也需要开源，闭源的话则需要向 QT 付费，QT 的价格非常昂贵，官网的专业版价格是每个开发者每年3620美元。而且使用 QT 会完全依赖于 QT 的库，可以理解成 windows 的 sdk，android 的 ndk，ios 的 sdk。
因此，如果使用 QT 的库，并且闭源发布的话，则必须购买它的授权，也就是3620美元每开发者每年，相比之下，windows的 sdk,android的 NDK是免费的，iososx 的 sdk如果要发布上架也就是每企业600多元人民币每年。
如果开放麒麟主推 QT 来做开发的话，起码一点就是要提供类似 QT 的有自主产权的免费 SDK，这样才能构建出可持续发展的生态来。
也有朋友觉得现在的系统无非就是Windows和苹果系统，还有一种是开源无版权的linux系统。如果想做操作系统替代，现在最好的途径就是推广linux。linux的生命力在于开源和互助，在于linux爱好者聚集的开源社区，集大家的智慧壮大系统，社区的参与者可以有个人，公司，政府机构，正所谓星星之火可以燎原。现在这些打着国产系统幌子的厂商用Windows的垄断性模式去运作linux，而不是在某个关键点发力。最后只能是失败。
网上还有不少人质疑为何不跟华为鸿蒙合作。事实上，鸿蒙主要是在嵌入式领域发挥作用。而麒麟（国家选定的PK体系中的K）主要做桌面系统，两者并不冲突。
多说一点：PK体系是目前国家主流选择。P是指银河飞腾，K就是麒麟。关键应用必须移植到PK体系上。
不好，坑挺多的，只能说勉强能用
如果是主打桌面端，顺手做个安卓端，可以。
想专门去开发安卓的话，建议还是用Java吧
首先新的操作系统面临的最大难点就是生态链的构造，相比安卓他们真的有能力提供更加智能的开发套件吗？他们真的有能力把python优化到c++的执行效率吗？那么他们有什么优势吸引开发者呢？
很多人已经论述很多了。首先鸿蒙不太可能不兼容Android（这里所说的兼容是指代码级兼容，并非运行级兼容，亦即，开发人员通过不太多的额外工作，就能做到让应用既能在Android上运行也能在鸿蒙上运行）。否则的话，像MeeGO一样强制使用Qt，鸿蒙将迫使程序员面临巨大的职业选择难题（决定是否放弃Java而转向C++），最终像MeeGO一样遭到弃用。至少在早期，鸿蒙完全不具备这样的号召力。因此，鸿蒙在本质上很可能是一个用更聪明的编译器编译出来的在更优化的Linux环境下运行应用的中间件。在这方面，恕我直言，似乎看不到有非常光明的未来。Android从1.0到9.0，已经把Java语言在移动平台上遇到的各种问题解决得比较好了，也许速度还能再快一些，但是已经不是决定因素。当年的WindowsPhone和Symbian速度都很快，使用很流畅，但有用吗？
还有很多人寄希望于国家强制推广鸿蒙，这个在政府集采市场是有可能的，但在消费者市场则可能性非常小。强制推广鸿蒙，意味着小米、OPPO、Vivo、一加等品牌都成了殉葬品，可能还要面临三星、苹果等公司在国际上的诉讼和折腾，更要命的是国内移动通信平台将由于被独家技术彻底垄断而变得脆弱，华为的些许技术欠缺将导致非常大的影响，国家不会为鸿蒙冒这么大的风险。
鸿蒙很难成功。注意是很难，不是绝对不能。
如果18年之前问这个问题，我确定的回答，不会成功。因为一个系统的生态太难建设了。连系统大佬微软+手机大佬诺基亚都折戟在这上面。阿里的阿里云手机系统也已经偃旗息鼓。你就可以看到它有多难了。而为什么18年后有可能，为啥？因为都是逼出来的的。谷歌现在已经开始限制华为使用了。任何事情有人逼你去做，你总能发挥出巨大的潜力。
而且华为从舆论上，人心上有很大优势。尤其是在中国。人心可用，得人心者的天下嘛。不要以为只是一个口号。人家一巴掌打过来。华为用手挡着了。还要甩手打过去。你不支持吗？这时候华为出系统，即使前期有很多不如意，大家都会谅解。这在一个互联网舆论可以解决很多事的现在，太宝贵了。所以华为应该早一点出，因为很多人等着它的系统，不要忘记连系统的名字都是网友起的。华为说的很清楚，之前是没有计划华为系统的，但是媒体已经很确定是华为有手机系统，并且叫鸿蒙。华为开始做手机系统，也就自然而然选择了这个名称。这就叫借势。
而且我们知道鸿蒙系统是要兼容安卓应用的，这就很大程度上可以解决软件生态问题。如果完全重起炉灶那就很难了，从开发成本来说就很难了，毕竟多一个系统，就多一份工作。
第二个问题,国内其他厂商会不会采用，这个要看具体华为系统的开放程度，如果是开源，那有可能。如果不是，那100%别的厂商不会用。
不想当将军的士兵不是好士兵，同样不想拥有自己系统的手机厂商是没有理想的手机厂商。谁也不会把自己的命根交给别人看管，为什么现在手机厂商愿意用安卓，就是因为安卓是开源的，大家都可以用。谷歌有所有权，但没有管理权。这个系统都可以从底层来修改。可以删减或加入自己的东西。所以大家才原因用它。
如果有厂商用鸿蒙系统，华为本身就是做手机的，还用它的系统。那岂不是运动员和裁判赛跑。就天然处于劣势。就像 游戏 厂商不会用腾讯云。电商不会用阿里云一样。谁也不会把关键的东西交给竞争对手。
所以其他厂商用鸿蒙系统是不可能的。
华为鸿蒙系统会不会成功要等他出了，体验到才知道，现在说他成不成功也只是嘴巴里说说，按照华为最近发的硬件来说，偏硬件来补充软件，系统主要还是要开发者，而开发者到你系统做一个app就要考虑你给的利润。好比如ios，3/7分，国外安卓1/9分，国内分成不定，比如腾讯至少和oppo商店就吵架过，腾讯要求oppo商店下载的腾讯新手游要5/5分，所以说鸿蒙系统要做好，第一就是和开发者利润空间，厂家会不会的话，这点我可以很明显和你说，不会，不敢得罪谷歌是一码，厂家干嘛帮别人养大孩子，国产手机竞争激烈，你死掉，我利润就赚到。
没有大的变革是不可能成功的!
1.想建生态很难，就算国家出面，国外肯定不会听!国内的市场又满足不了这么多手机厂商!舍掉谁对国家都是损失!
2.腾讯 游戏 负优化华为系统不知真假，但是一个把柄放人家手里没人会愿意，除非华为不做手机，不然不会有手机厂商愿意接入
支持国货，支持华为。
相信每一个国人都是这么想的。
华为胡蒙系统！真实的菊花。哈哈哈哈！
不看好，底层还是人家的
这主要体现在一下3点：1.关于跨平台： Qt的一大优势就是跨平台，一份代码若准守Qt标准开发，那么理论上可以跨所有Qt支持的平台并且不需要修改。但是这个是有代价的。比如说对于iOS平台，若用OC或者swift，可能用1份的开发时间就可以完成开发，但是用Qt可能是1.5份。这主要体现在Qt在移动平台没有提供现成的、成熟的（Qt目前有一个lab，是一个控件包，针对移动平台有做优化，但是还在测试阶段）控件供应开发者使用。比如说Qt没有侧滑窗口、没有滑动返回、没有顶部状态栏，很多东西都需要自己造轮子，非常浪费时间，而且效果不一定好。我记得5.5的时候，连访问系统相册这个功能都没有，要自己写OC代码去访问，不过5.6加上了。这个开发的工作量，对于一个没有跨平台需求的App，明显是不合适的。但是如果有跨平台需求，那么可能是1.5份的开发量，就可以获得iOS+Android两份平台的App，相比2份的开发量性价比就上来了。而且如果有需求还可以部署到WP、UbuntuPhone等移动平台。2.关于Quick Qt从5开始，就主推界面用Quick开发（Quick是框架，QML是配合Quick的一个语言），然后用C++开发复杂的逻辑。这个愿景是好的，但是推行真的很慢。这是因为新的框架也就是Quick，带来了新的学习成本，这个直接就吓跑了很多人。我知道很多用Qt的人，即使开发了N年Widgets，对Qucik也可能都是完全没有接触的状态。当然Quick本身是好的，相比Widgets开发效率高、漂亮、运行速度快。另外，如果是Widgets开发移动端App，我建议你直接打消这个念头，还是算了。这主要是因为用Widgets开发的程序，各方面实在是太差了。比如说Widgets很多界面都是CPU绘制的，然后移动平台CPU本来就弱，这就导致了界面很卡。还有开发效率也低。3.关于成熟度 从目前Qt5.6的角度看，已经加入了很多以前没有的模块了，我觉得用于Qt开发一些基础的App，已经完全可以胜任了。但是对于功能复杂的App，我建议还是权衡一下比较好。还有就是现在很多SDK包，都只对原生框架做了适配，用Qt开发意味着还是要回到原生框架去处理一些通讯、交互什么的，这个也要注意。
不看好Qt for Android。以下简称QfA.
1. 跨平台只在pc上有优势，在移动设备上毫无优势。移动设备整体的应用风格需要保持一致，你外部加进来一个ui，倒是和平台保持一致了。你如何保持和原生ui的这种使用一致性。
2.在开发易用度上，Android(java) api 已经做得很好，包括事件，广播，服务等Qt里有的基本上Android api里已经做得很好，从Qt开发者转为java开发者也很容易。 而如果要写QfA应用，开发者不仅要懂Qt，同样也避免不了要写java代码。
3. 如果要写和其它app通信的时候,QfA的灾难性就来了。如果是上层的几乎等完整的搞一遍Android api吧。 另外对于和设备相关的一些调用(GPS/Telephony)等,QfA的工作量一下子就上来了，这时候你还指望qml么？
4.性能呢？ QfA对于图形渲染区的请求还得在java的接口请求，是不是又要绕了个大弯。
5. 软件体积。 终端用户要用Qt app，势必要先装一个Qt lib， 或者在你的app 中一起静态发布。
在有很多优秀的QfA app出现之前，大家不带乐意只为一个好的app 去装一个大的软件，而会愿意选择一个原生软件替代。
重庆分公司
重庆分公司
