qt中gif編譯結果
Ⅰ 拿到了一份前輩的QT源碼，打算重新編譯一下，出現如下錯誤信息，有大神知道什麼原因，怎麼破解嗎
估計你不滿足他編譯設置條件，錯誤說/MP應該是一個文件或者目錄，但是並不存在
Ⅱ Qt 編譯好的 可執行文件 不能運行是怎麼回事
缺少動態鏈接庫，你的qt是動態編譯的，根據提示上你qt的安裝目錄上考到你的exe文件夾里
Ⅲ qt保存gif圖片
qt不能保存gif格式圖片，除非你自己用qt寫一個編輯gif圖片的程序，這個很麻煩，你得知道gif的文件格式。
臨時要用不如寫個exe好了，用最短時間不停的更換圖片，感覺像是gif一樣，哈哈
Ⅳ Qt如何實現靜態編譯與動態編譯共存
通常不需要在系統變數中加入Qt庫的位置的。Qt Creator可以自動掃描到系統中存在的Qt庫版本，如果掃描不到，可以通過Creator的 Tool->Options->Qt4中添加靜態庫的路徑。而QDevelop雖然沒有那麼智能，但是可以手動指定INCLUDE和LIB的位置。或許，這根本就不是一個問題。如果懷念動態庫，或者在產品發布之前並不想體驗靜態編譯那種蝸牛爬一般的速度，可以在pro文件中指定CONFIG += shared，而且，要記得在Project中選擇相應的版本。
Ⅳ Qt交叉編譯遇到的問題
QT相關的安裝軟體包：
(1) tmake-1.13.tar.gz （編譯工具，如progen與tmake）
(2) qt-embedded-2.3.7.tar.gz （提供了qte的庫）
(3) qt-x11-2.3.2.tar.gz （為了生成相應的QT工具，如designer和qvfb等）
(4) qtopia-free-1.7.0.tar.gz （QTE的桌面環境程序）
(5) cross-3.3.2.tar.bz2 （交叉編譯工具）
一、安裝工具
1 安裝 tmake
在 linux 命令模式下運行以下命令:
tar xfz tmake-1.11.tar.gz
export TMAKEDIR=$PWD/tmake-1.11
export TMAKEPATH=$TMAKEDIR/lib/qws/linux-x86-g++
export PATH=$TMAKEDIR/bin:$PATH
2 安裝 Qt/Embedded 2.3.7
在 Linux 命令模式下運行以下命令:
tar xfz qt-embedded-2.3.7.tar.gz
cd qt-2.3.7
export QTDIR=$PWD
export QTEDIR=$QTDIR
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
./configure –qconfig local–qvfb -depths 4,8,16,32
make sub-src
cd ..
上述命令 ./configure -qconfig -qvfb -depths 4,8,16,32 指定 Qt 嵌入式開發包生成虛擬緩沖幀工具qvfb,並支持 4,8,16,32 位的顯示顏色深度。另外我們也可以在 configure 的參數中添加-system-jpeg 和 gif,使 Qt/Embedded 平台能支持 jpeg、gif 格式的圖形。
上述命令 make sub-src 指定按精簡方式編譯開發包,也就是說有些 Qt 類未被編譯。Qt 嵌入式開發包有 5種編譯范圍的選項,使用這些選項,可控制 Qt 生成的庫文件的大小,但是您的應用所使用到的一些 Qt 類將可能因此在 Qt 的庫中找不到鏈接。編譯選項的具體用法可運行./configure -help 命令查看。
在這一過程的configure中出現了問題：有一個變數沒有聲明，發現是少了一個頭文件，加上即可，make順利通過，看到了enjoy！
3 安裝 Qt/X11 2.3.2
在 Linux 命令模式下運行以下命令:
tar xfz qt-x11-2.3.2.tar.gz
cd qt-2.3.2
export QTDIR=$PWD
export PATH=$QTDIR/bin:$PATH
export LD_LIBRARY_PATH=$QTDIR/lib:$LD_LIBRARY_PATH
./configure -no-opengl
make
make -C tools/qvfb
mv tools/qvfb/qvfb bin
cp bin/uic $QTEDIR/bin
cd ..
根據開發者本身的開發環境,也可以在 configure 的參數中添加別的參數, 比如-no-opengl 或-no-xfs,可以鍵入./configure -help 來獲得一些幫助信息。
在這個安裝過程中也出現了很多錯誤，典型的就是在make過程中：
/usr/local/qt-2.3.2/include/qvaluestack.h:57: error: cannot convert 'QValueListIterator<QMap<QString, QString> >' to 'const char*' for argument '1' to 'int remove(const char*)'
/usr/local/qt-2.3.2/include/qvaluestack.h: In member function 'T QValueStack<T>::pop() [with T = QString]':
xml/qxml.cpp:2502: instantiated from here
/usr/local/qt-2.3.2/include/qvaluestack.h:57: error: cannot convert 'QValueListIterator<QString>' to 'const char*' for argument '1' to 'int remove(const char*)'
make[2]: *** [xml/qxml.o] Error 1
make[2]: Leaving directory `/usr/local/qt-2.3.2/src'
make[1]: *** [sub-src] Error 2
make[1]: Leaving directory `/usr/local/qt-2.3.2'
make: *** [init] Error 2
這個錯誤是說，在文件qvaluestack.h的57行出錯。改正方法是修改文件qt-2.3.2/ include/qvaluestack.h的 第57行，將remove( this->fromLast() );改為 this->remove( this->fromLast() );
修改時可能要更改文件許可權，變成可寫的，chmod 666 qvaluestack.h。然後make順利通過，看到了enjoy。
二、交叉編譯 Qt/Embedded 的庫
開發居於 Qt/Embedded 的應用程序要使用到 Qt/Embedded 的庫,編寫的 Qt 嵌入式應用程序最終是在YLE270開發板上運行的,因此在把 Qt 嵌入式應用程序編譯成支持 YLE270 的目標代碼之前,需要兩樣東西,一個是 arm9 的 linux 編譯器,另一個是經 arm9 的linux 編譯器編譯過的 Qt/Embedded 的庫。安裝交叉編譯工具 cross-3.3.2 前面已經安裝過了。
這一步主要是配置 Qt/Embedded2.3.7 的安裝，Qt/Embedded 的安裝選項有很多個,您可以在命令行下直接輸入「./configure」來運行配置,這時安裝程序會一步一步提示你輸入安裝選項。您也可以在「./configure」後輸入多個安裝選項直接完成安裝的配置。在這些選項中有一個選項決定了編譯 Qt/Embedded 庫的范圍,即可以指定以最小,小,中,大,完全 5 種方式編譯 Qt/Embedded 庫。另外 Qt/Embedded 的安裝選項還允許我們自己定製一個配置文件,來有選擇的編譯 Qt/Embedded 庫,這個安裝選項是「-qconfig local」 ;當我們指定這個選項時,Qt/Embedded庫在安裝過程中會尋找qt-2.3.7/src/tools/qconfig-local.h 這個文件,如找到這個文件,就會以該文件裡面定義的宏,來編譯鏈接 Qt/Embedded 庫。
具體過程如下:
cd qt-2.3.7
export QTDIR=$PWD
export QTEDIR=$QTDIR
make clean
./configure –xplatform linux-arm-g++ -shared –debug (接下行)
-qconfig local -qvfb -depths 4,8,16,32
make
cd ..
在make中出現了錯誤，有變數沒有聲明，原來是優龍公司為了避免初學者在一開始就直接接觸到 Qt/Embedde 的復雜的宏編譯選項,把這些宏定義到一個名為 qconfig-local.h的安裝配置文件中,在安裝 Qt/Embedded 的時候,需要把這個文件復制到 Qt/Embedded 的安裝路徑的/src/tools 子路徑下，
cp /配置文件所在路徑/qconfig-local.h ./src/tools
make順利通過，看到了enjoy。
最後就可以在命令行下輸入make 命令對整個工程進行編譯鏈接了，在這里，要把過程中產生的文件放在同一個文件夾裡面，方便應用。
在最後make完畢以後我還是遇到了一個問題，就是生成的可執行文件不能運行，運行時提示：./hello cannot execute binary file,當然不能直接在自己的主機上運行了，因為生成的二進制文件要下到板子上運行的。接上液晶屏，板子上電，把生成的可執行文件下載到板子上，要chmod一下，不然許可權不夠，終於在液晶屏上看到了自己弄的小程序，好開心！
三、添加一個 Qt/Embedded 應用到 QPE
以hello，world！為例
1 在工作的機器上解包 qtopia
tar zxvf qtopia-free-1.7.x.tar.gz
cd qtopia-free-1.7.x
export QTDIR=$QTEDIR
export QPEDIR=$PWD
export PATH=$QPEDIR/bin:$PATH
注意在上面已經設定環境變數 QPEDIR 為 QPE 的安裝(解包)路徑。
2 建立 Hello,World 的例子程序的圖標文件
方法是:製作一個 32 X 32 大小的 PNG 格式的圖標文件,將該文件存放在$QPEDIR/pics/inline 目錄下,然後使用以下命令將$QPEDIR/pics/inline 目錄下的所有圖形文件轉換成為一個 c 語言的頭文件,這個頭文件包含了該目錄下的圖形文件的 rgb 信息。
qembed --images $QPEDIR/pics/inline/*.*
> $QPEDIR/src/libraries/qtopia/inlinepics_p.h
3 交叉編譯 qtopia
在$QPEDIR 路徑下,運行以下命令
cd src
./configure –platform linux-arm-g++
make
cd ..
在這一過程中也出現了比較大的錯誤，在make的時候又出現了error，是resource.cpp的174行的變數qembed_findImage沒有聲明，考慮到以前遇到的情況，推斷可能是少了某個頭文件，但是又不知道是哪一個，google了很久都沒有找到解決辦法，沒辦法只好點開src/libraries/qtopia下面的每一個頭文件看了一遍，還是沒有發現有含有這個變數的文件，繼續google，然後發現了inlinepics_p.h中包含qembed_findImage，於是vi /usr/local/qtopia-free-1.7.0/src/libraries/qtopia/inlinepics_p.h，發現inlinepics_p.h是空白的，原來是
qembed --images $QPEDIR/pics/inline/*.*
> $QPEDIR/src/libraries/qtopia/inlinepics_p.h
出了錯誤，重新操作一遍這一步，再查看inlinepics_p.h，發現正常了，要繼續交叉編譯qtopia：
make clean
./configure –platform linux-arm-g++
Ⅵ 為什麼 Qt Creator 的編譯如此之慢
取自知乎上的一篇文章
作者：姚冬
我是來反對樓上某些答案的。
我曾經用MFC寫了金山詞霸（大約20多萬行），又用Qt寫了YY語音（大約100多萬行），算是對兩種框架都比較有經驗。
糾正幾個錯誤的認識。
1. 「用Qt寫的程序編譯比MFC慢」的說法是錯誤的
絕對錯誤，單位代碼行數編譯Qt遠比MFC快得多，因為Qt庫的頭文件設計非常好，盡量都使用了前置聲明，避免了頭文件嵌套，幾乎所有類都使用了公有類和私有類的設計，把沒必要公開的聲明放到私有頭文件里，避免了編譯時引入過多代碼。而MFC沒有這樣的設計。
至於大家感覺MFC快主要原因是MFC工程默認打開了編譯預處理頭文件（PCH），但是這是VC編譯器的特性，所有C++程序都可以用，不是MFC特有，Qt也可以使用 PCH
方法很簡單，在你的 .pro 文件中加入一行
PRECOMPILED_HEADER = stable.h
指定 Stable.h這個頭文件作為編譯預處理文件，MFC里這個文件一般叫stdafx.h
然後在 stable.h里 包含你所用到的所有 Qt 頭文件，如果你用了很多qt的類可以直接包含所有
比如 ：
#include <QtCore>
#include <QtGui>
這兩個文件里又包含了幾乎所有Qt常用類
不用擔心，即使包含了所有頭文件也沒關系，有了PCH再多頭文件也沒影響。
如果你還想編譯再快點，可以在 .pro里加入下面一行
QMAKE_CXXFLAGS += /MP
指定/mp編譯選項，編譯器將使用並行編譯，同時起多個編譯進程並行編譯不同的cpp
而且QT這種引入PCH的方法比MFC的好，由於MFC的PCH選項是每個工程逐個指定的，很容易被某些人搞壞，我曾經無數次修復PCH問題，但是Qt的選項是寫在.pro里的，寫一次就永遠不會錯。
MFC一旦弄壞了PCH，編譯也慢得令人發指。
給個參考時間吧，YY最新版本大約 100多萬行C++代碼，rebuild debug和releae總共需要20多分鍾，機器是i5 四核SSD硬碟。其實對於大項目硬碟才是瓶頸，如果換機械硬碟要慢差不多70%，有個同事用10G內存做了個內存檔編譯，還能快30%。
如果你比這個慢，請檢查自己的代碼問題。
2. 「QT本身編譯慢」的說法是錯的
Qt本身其實編譯並不慢，慢的是webkit庫和例子程序，你如果不改任何選項默認是會編譯所有的，webkit本身就是個恐龍級項目，用了太多泛型技術，編譯非常慢。另外Qt里附帶了數百個例子工程，都編譯一邊也很慢。如果僅編譯QT核心庫是很快的，比如QtCore只需要1分鍾，QtGui大約5分鍾。
送個福利（僅限windows vc＋＋ 2008）：
configure.exe -qt-libjpeg -qt-zlib -qt-libpng -qt-libjpeg -qt-gif -no-libtiff -no-libmng -nomake examples -nomake demos -no-webkit -nomake doc -no-plugin-manifests -no-exceptions -no-rtti -no-qt3support -no-openssl -no-opengl -no-multimedia -no-3dnow -no-native-gestures -no-style-motif -no-style-cde -no-style-cleanlooks -no-style-plastique -no-sql-sqlite -no-dbus -platform win32-msvc2008
這是我自己用的Qt編譯前的配置命令行，把我自己用不到的都去掉了，這樣配置編譯就快很多了。
我把 webkit examples demos 等大傢伙都去掉了。如果你真的需要這些，可以安裝Qt sdk裡面有編譯好的版本。
補充：Qt creator只是IDE，不是編譯器，編譯慢真的不關他的事，要看你具體用的編譯器是什麼。一般來說在Windows下就是minGW，也就是一個移植版本的GCC，的確是不如VC++里的CL快的。
如果是其它平台，那麼編譯器可以換成LLVM的clang，那就快很多了。
在Windows下來是用VC++吧，推薦VC2008，Qt和VC的IDE結合非常好，我現在的項目都是用VC2008+QT的，開發效率很高，記得裝Visual Assist哦。
qmake -tp vc
可以用 .pro生產 .vcproj的VC工程文件，可以用VC++打開編譯。
Ⅶ 請哪位來解釋一下Qt靜態編譯和動態編譯的區別
靜態編譯與動態編譯的區別：
1、動態編譯的可執行文件需要附帶一個的動態鏈接庫，在執行時，需要調用其對應動態鏈接庫中的命令。
所以其優點一方面是縮小了執行文件本身的體積，另一方面是加快了編譯速度，節省了系統資源。
缺點一是哪怕是很簡單的程序，只用到了鏈接庫中的一兩條命令，也需要附帶一個相對龐大的鏈接庫；二是如果其他計算機上沒有安裝對應的運行庫，則用動態編譯的可執行文件就不能運行。