wxWidgets的安裝編譯、相關配置、問題分析處理


一、介紹部分 (win7 下的 GUI 效果圖見 本篇文章的最后部分截圖2張)

wxWidgets是一個開源的跨平台的C++構架庫(framework),它可以提供GUI(圖形用戶界面)和其它工具。目前的2.x版本支持所有版本的Windows、帶GTK+或Motif的Unix和MacOS。相當於大家熟悉的 VC++。

二、wxWidgets的安裝與編譯:

二.1 基礎部分

編譯是少不了的操作,即使你下載的是安裝包,因為這個安裝包只是相當於自解壓包,我們還需要將其進行編譯,才能得到wxWidgets在Windows可用的庫。

如果你在參考了許多編譯文檔或教程之后發現還是沒有編譯出某些庫文件,如

wxbase28u_gcc_custom.dll

libwxmsw28ud_gl

libwxmsw28u_gl

libwxmsw28u_dbgrid

libwxmsw28ud_dbgrid

wxbase28ud_gcc_custom.dll

wxbase28u_gcc_custom.dll

(部分文件可能會有擴展名的缺少而不同)

這里使用的版本是wxWidgets 2.8.12(上面文件名中的28也是指這前兩位版本號2.8,版本2.9的同理)

在本文發表之時,wxWidgets 2.8.12是當前的穩定版。如下,

Latest Development Release: 2.9.5
Current Stable Release: 2.8.12
Previous Stable Release: 2.6.4

下載地址:http://www.wxwidgets.org/downloads/

http://prdownloads.sourceforge.net/wxwindows/wxMSW-2.8.12.zip (MSW=MS Windows

先檢查一下系統的環境變量中有無Mingw3232位)的bin目錄的值,集成安裝的大致安裝位置是 C:\CodeBlocks\MinGW\bin ,要用到的是其中的mingw32-make.exe 。

環境變量的設置,此外設置用戶變量(系統變量要重啟才行,並且對所有用戶都有效),只要簡單注銷一下當前用戶即可生效(而用path 命令設置有時不生效)。

在這里說一下,一般會用到的與本IDE設置有關的環境變量,

是編譯環境用到的bin 目錄,即大致類似於 C:\CodeBlocks\MinGW\bin 

調用庫文件時用到的編譯完成后,放置生成的庫文件的目錄。這個目錄下面會說到。

 

 

解壓下載的壓縮包,並進入 wxMSW-2.8.12\build\msw子目錄,打開命令行切換到這一目錄(或在這個文件夾空白處按住Shift,並右鍵,選擇“在此處打開命令窗口”,直接進入)。因為前面設置好了環境變量(不論是用戶級的,還是系統級的,最后,再打開cmd.exe,執行 path 檢查一下是否添加成功

編譯時用到的命令,如果用它,就按下文件相關,修改 config.gcc 文件后,執行

mingw32-make.exe -f makefile.gcc (無參數,參數寫在config.gcc中)其中的 -f 是 file,為mingw32-make.exe指定要編譯的文件 makefile.gcc。

如果不寫在配置文件中,則可以寫成如下示例(只是動態庫SHARED=1)

mingw32-make -f makefile.gcc BUILD=release SHARED=1 UNICODE=1    (release 版本)

mingw32-make -f makefile.gcc BUILD=debug SHARED=1 UNICODE=1    (debug 版本)

 


 下面是完整的config.gcc文件內容,在看之前,請先略看,並跳到下面的內容,但在正式編譯時,請細看下面內容,即使你用的是加了參數的編譯方法,如上面2條命令,可能會無法編譯出某些文件。圖形界面開發,要考慮的地方很多,入門后,自然更加熟練:

# =========================================================================

#     This configuration file was generated by

#     Bakefile 0.2.9 (http://www.bakefile.org)

#     Beware that all changes made to this file will be overwritten next

#     time you run Bakefile!

# =========================================================================

 

 

# -------------------------------------------------------------------------

# These are configurable options:

# -------------------------------------------------------------------------

#設置是否共享生成的庫文件(先默認如下)

# Compiler flags to link shared library 

LINK_DLL_FLAGS ?= -shared

 

# Compiler flags to link loadable module 

LINK_MODULE_FLAGS ?= -shared

#編譯器(這個不能動,其它的編譯器也有對應的 config.***文件)

# C compiler 

CC = gcc

 

# C++ compiler 

CXX = g++

#下面的幾條,與編譯時占用的CPU等系統資源有關,可能。

# Standard flags for CC 

CFLAGS ?= 

 

# Standard flags for C++ 

CXXFLAGS ?= 

 

# Standard preprocessor flags (common for CC and CXX) 

CPPFLAGS ?= 

 

# Standard linker flags 

LDFLAGS ?= 

 

# The C preprocessor 

CPP ?= $(CC) -E

#靜態庫 0 、動態庫 1 

# What type of library to build? [0,1]

SHARED ?= 0

#沒了解(默認)

# Build wxUniversal instead of native port? [0,1]

WXUNIV ?= 0

#支持寬字符集,必須是1

# Compile Unicode build of wxWidgets? [0,1]

UNICODE ?= 1

 

# Use MSLU library when building Unicode version. [0,1]

MSLU ?= 0

#編譯的二進制的類型:Debug、Release(這兩個都要編譯,方便以后用到)

# Type of compiled binaries [debug,release]

BUILD ?= release

#這里說一下,下面的參數,能開的基本上都開了,但個別的會說明一下作用。

# Should debugging info be included in the executables? The default value

# "default" means that debug info will be included if BUILD=debug

# and not included if BUILD=release. [0,1,default]

DEBUG_INFO ?= default

# Should __WXDEBUG__ be defined? The default value "default" means that it will

# be defined if BUILD=debug and not defined if BUILD=release. [0,1,default]

DEBUG_FLAG ?= default

#是編譯分開的多個庫,還是一個大的整體(如果選擇1,會無法得到目標庫,生成的庫是以monolithic 為前綴的,而且很大)

# Multiple libraries or single huge monolithic one? [0,1]

MONOLITHIC ?= 0

#圖形界面,少不了

# Build GUI libraries? [0,1]

USE_GUI ?= 1

 

# Build wxHTML library (USE_GUI must be 1)? [0,1]

USE_HTML ?= 1

 

# Build multimedia library (USE_GUI must be 1)? [0,1]

USE_MEDIA ?= 1

 

# Build wxXRC library (USE_GUI must be 1)? [0,1]

USE_XRC ?= 1

 

# Build wxAUI library (USE_GUI must be 1)? [0,1]

USE_AUI ?= 1

 

# Build wxRichTextCtrl library (USE_GUI must be 1)? [0,1]

USE_RICHTEXT ?= 1

 

# Build OpenGL canvas library (USE_GUI must be 1)? [0,1]

USE_OPENGL ?= 1

 

# Build ODBC database classes (USE_GUI must be 1)? [0,1]

USE_ODBC ?= 1

 

# Build quality assurance classes library (USE_GUI must be 1)? [0,1]

USE_QA ?= 1

 

# Enable exceptions in compiled code. [0,1]

USE_EXCEPTIONS ?= 1

 

# Enable run-time type information (RTTI) in compiled code. [0,1]

USE_RTTI ?= 1

 

# Enable threading in compiled code. [0,1]

USE_THREADS ?= 1

#下面這個參數在前面如果設置了編譯類型是Relesse是設置為1,Debug時為0(我在編譯時,后者Debug為1時中斷了)

# Enable wxCairoContext for platforms other than Linux/GTK. [0,1]

USE_CAIRO ?= 1

 

# Link with gdiplus.lib? (Needed for wxGraphicsContext, will also set wxUSE_GRAPHICS_CONTEXT) [0,1]

USE_GDIPLUS ?= 1

 

# Is this official build by wxWidgets developers? [0,1]

OFFICIAL_BUILD ?= 0

 

# Use this to name your customized DLLs differently 

VENDOR ?= custom

 

#  

WX_FLAVOUR ?= 

 

#  

WX_LIB_FLAVOUR ?= 

#下面的大概是特殊設置

# Name of your custom configuration. This affects directory

# where object files are stored as well as the location of

# compiled .lib files and setup.h under the lib/ toplevel directory. 

CFG ?= 

 

# Compiler flags needed to compile test suite in tests directory. If you want

# to run the tests, set it so that the compiler can find CppUnit headers. 

CPPUNIT_CFLAGS ?= 

 

# Linker flags needed to link test suite in tests directory. If you want

# to run the tests, include CppUnit library here. 

CPPUNIT_LIBS ?= 

 

# Version of C runtime library to use. You can change this to

# static if SHARED=0, but it is highly recommended to not do

# it if SHARED=1 unless you know what you are doing. [dynamic,static]

RUNTIME_LIBS ?= dynamic

 

# Set the version of your Mingw installation here.

#     "3" ...... this is for Mingw 2.0 or newer (comes with gcc3)

#     "2.95" ... for Mingw 1.1 or any of the older versions [3,2.95]

GCC_VERSION ?= 3

 config.gcc 配置文件結束!!


相關知識:節選自 http://wenku.baidu.com/view/69b0272216fc700abb68fcae.html 本文不作過多修改。

動態庫dll   vs.  靜態庫lib
從編譯結果上看,C++庫可以被編譯成“靜態”鏈接庫,也可以被編譯成“動態”鏈接庫。所謂“鏈接庫”的意思就是,庫自身並不可以被執行。應用程序才是可執行的,為了寫一個應用程序,可能需要用到很多功能,其中一些功能,應用程序的作者並不用自己實現,而是直接使用鏈接庫即可。把應用程序與庫在功能上進行合並的過程,就叫做過“鏈接”。如前所有述,有兩種鏈接方法:靜態或動態。

所謂“靜態鏈接”,就是直接把庫文件和可執行文件合二為一,形成一個文件。這種情況下,發布可執行文件時,就不必另外附加那個功能庫了;因為事實上那個功能庫已經“嵌入”在可執行文件中(可執行文件的體積,變大了)。靜態鏈接方法,適用於功能簡單應用程序。

所謂“動態鏈接”,是指程序在運行時,才會去尋找動態庫中所需要的功能,然后在內存中加載入動態庫。這種情況下,可執行文件與動態庫獨立存在,沒有合成一體,在發布程序時,你必須兩個文件一起安裝到用戶的電腦上。動態鏈接方法,適用於相對復雜的應程序,通常這種情況下,為了方便用戶安裝,我們會提供一個安裝程序。 另外,在Linux系統中,“動態鏈接庫”通常被稱為“共享庫”(文件擴展名也改為.so);這也說出了“動態鏈接”這項技術帶來的另一個好處:多個應用程序可以共用一個獨立的動態庫。

如果把蓋房子想像成寫程序的話,當我們需要建造其中的自來水系統時,可以把水庫當成是一種功能鏈接庫。那么,當我們是在鄉下自建一座獨門獨戶的小樓,那么可以采用“靜態鏈接”的方法,即在自家樓里砌個水庫,自個兒使用,當然這個自建的水庫往往增加了小樓的體積。來到城里,城里的一座高樓住着千家萬戶,這時,“動態鏈接”技術派上用上,所有住戶共享一個水庫,當你需要水時,打開水龍頭,水就從外部“動態”而來。

為了方便以后使用,今天wxWidgets將我們編譯成至少兩個版本,即動態庫和靜態庫 ,debug 和 release ,2x2=4,其它參數不變。而在CodeBlocks的工具欄中“build target”可以選擇你當前的編譯類型,並且相關的信息,可能也與這有關,具體去分析,我們一個也不能少

DEBUG vs. RELEASE
DEBUG 指“調試”版。表示編譯出所庫含有調試信息,這自然會讓庫變得很大,但有利於我們寫程序時跟蹤也發現錯誤。

RELEASE 指 “發行”版。表示我們認定程序寫得差不多了(能解決的問題都解決了,錯誤相對比較少),這時調試信息就不需要了,庫恢復它原來的大小。

為了方便調試與發而程序,DEBUG和RELEASE,同樣的,我們一個也不能少。

UNICODE vs. 非 UNICODE
傳統C++程序中,對普通的1個英文字符采用1個字節表示,而對1個漢字采用兩個字節表示。比如有這樣一句話:

“文件c:\abc\efg\我的文檔\奧運知識ABC\乒乓球基礎知識.txt無法打開!”

假設計數以0開始,那么例子中那句話,第0個字符是“文”字的前半個字符,第1個字符則是“文”字的后半個字符。事實上半個漢字是沒意義的,它只會為字符串處理上帶來困難。比如,假設我們要把上述那句話顯示在顯示在某個窗口上,但由於窗口太小,顯示不下這時我們希望將那句話的截掉一點,結果類似:

“文件c:\abc\efg\我的文檔\奧運知識ABC\乒乓球基...”

這個過程看似簡單,但其實復雜,如果不進行特殊的處理,程序很要可能會在某個漢字的半個字符處截斷那句話,而1個漢字一旦被“腰斬”了,剩下的那個半個漢字,無論是上半身還是下半身,就會在屏幕上顯示亂碼。

解決這個問題,方法有很多種,其中采用“UNICODE”是個相對通行而簡單的辦法,並且解決得比較徹底。“UNICODE”的方案說起來也簡單,就是用兩個字節甚至四個字節去表達一個字符(無論是英文字符還是中文、日語等)。

相關知識 結束!


 

二.2 目錄知識

要處理漢字,所以在編譯過程,我們只選擇UNICODE的方案,故會編譯 4 次。每次30分鍾左右,計算機配置高的話,可以同時進行兩次。由於只是需最終編譯的庫,推薦的方法是,將目錄 wxMSW-2.8.12/ 復制4份,每一份均作相應的編譯。 然后將目錄進行合並,我們最終需要的不是build目錄下的文件,而是程序根目錄 lib 中的庫文件。參考下面的表格,就能得出庫文件的命名機制,見表格中的【注】,所以4次編譯不會出現庫文件重名,只是相似。

 編譯完成后,在msw目錄下生成的目錄如表格,返回到 wxMSW-2.8.12\lib 目錄,我們發現多了 gcc_lib(靜態)或gcc_dll()動態

    庫類型
靜態=0
動態=1
編譯時下面目錄下會生成子目錄
wxMSW-2.8.12\build\msw\
編譯時下面目錄下
會生成子目錄
wxMSW-2.8.12\lib
Unicode debug 動態 gcc_mswuddll gcc_dll
靜態 gcc_mswud gcc_lib
release 動態 gcc_mswudll gcc_dll
靜態 gcc_mswu gcc_lib
上面3項知識詳見下文 【注】:gcc_msw(gcc編譯的windows庫),
u=unicode,d=debug,dll=動態,
lib=靜態(略寫),r=release(略寫)
gcc_dll的目錄下有
 mswu 或 mswud
gcc_lib的目錄下有
 mswu 或 mswud

相關目錄及操作 的截圖參考:

1 編譯過程,剛剛開始,即被我無情 Ctrl + C 終止。提示,編譯前要先考慮是否如上面示例修改 config.gcc 文件。時間:30分鍾左右。

2 msw 目錄下的兩個主要文件 :配置 - config.gcc、及 makefile.gcc 。目錄 gcc_mswu 在編譯之前不存在(顯然這是編譯的 Unicode + 靜態庫 + Release

3 lib 目錄下編譯后的文件目錄結構,目錄“_sc”及下面的3個文件在不同的編譯條件下不會變化。這里要提到的是前面在環境變量部分沒有講完的第2個環境變量,雖然不是必須,但是這種解決問題或排除程序報錯的方法是很重要的。參考下面的圖片,一一說來。

4 進入上圖的 gcc_lib ,里面的目錄結構如下圖,包括各種 (Unicode + 靜態庫 + Release),其中的 mswu 目錄下的文件有時也會因為缺少而報錯,比如其子子目錄中的 setup.h 。

5 如果大家采用我的方法,將靜態庫、動態庫分別合並到 gcc_lib 及 gcc_dll ,下圖就是相應結果:

關於此處涉及到的環境變量問題在這里細說一下,按照下圖的庫文件放置方法在編譯時會報錯,大多是找不到某某文件,而你到這個目錄下查找,卻發現文件在那呀!

CodeBlocks 創建 Project 時會的步驟要求你選擇 wxWidgets 的存放目錄,編譯時編譯器就會從這個目錄下找 lib 下的庫文件,但不會找子目錄下的文件。因而,如下圖放置庫文件,會提示缺少相關文件。那么,怎么辦?有兩種辦法。

1 將 gcc_lib 及 gcc_dll 加到環境變量中

2 直接把 gcc_lib 及 gcc_dll 里面的文件及目錄全部移動到 lib 根目錄下。不上圖了,移動時不用擔心文件或目錄重名。

這種方法是重點:前提是你編譯出了這個文件,編譯時提示找不到某文件,就將其放置在環境變量中。其實初期使用時擔心的都是缺少文件的報錯,這你真心沒辦法。So,花點時間在編譯工作上吧,沒有壞處的!! 

 

三、供參考的相關資料:

 

 http://blog.sina.com.cn/s/blog_5dbdcfc701013kiw.html

 http://wiki.codeblocks.org/index.php?title=WxSmith_tutorial:_Hello_world (圖形界面重點入門參考,全英文。雖然,與本篇版本不同,但不出錯。用 wxFormBuilder,就不如用集成的wxSmith,知其一,則知它們)

 

 四、相關問題羅列:

1 編譯器版本與庫文件的關系,前面也有提到,如果使用了別人編譯的庫,最好就要用編譯這個庫使用的編譯器版本,即使只是版本號不同。這里也發現為什么linux下提供的程序多為源碼,使用時需要編譯,有編譯器版本與庫文件不對應的原因,就像一台組裝機,必需要考慮硬件不兼容問題。而這個問題在windows及MacOS下很少,因為這些平台下的程序所需調用的庫大多內置在了程序中。雖然體積會大點,卻得到了體驗。回想一下,桌面版本linux 六個月一次升級,大多數程序都要同時重新編譯,拿播放器 VLC 來說,在Fedora 上就要為是Fedora 18 及 Fedora 19 而分別編譯發行版本(這個可能會不用在本機編譯了);而服務器版Linux很少升級,是為避開這個問題,服務器上的各種服務器軟件,怎么能夠奔命於編譯、編譯、再編譯的過程,而連基本服務都沒做好。導致原因,不能與它的自由,開源脫開關系。所以,Linux會有那么一個階段,分久必合,大家坐下來 制定一個ISO標准,這為的是長遠發展,但不能失去了它的根本:自由、開源。我曾經與朋友打了這么一個比喻,linux像組裝機,各種配件,自由搭配,只要沒有兼容性問題;Windows 則是品牌機,辦公、影音、游戲,應有盡有。物盡其用,最終提供服務的是應用程序,而它們跑在系統的大車之上。

2 64位 或 32位 系統的影響,雖說,用的是32位的編譯器,可編譯出來的程序在我64拉win7上部分效果不能實現,而拷貝到32位win7上,運行良好(如果缺少文件,就在本機上復制它到目標電腦system32目錄,這個目錄是系統默認加入到環境變量中的)。不過可能只是一面之詞,畢竟只是我一台機子上的現象,而我的電腦用運行着 HIPS (Comodo防火牆內置)

3 網上有一種 wxpack 是庫文件編譯好的,但現在新版本的沒有編譯了,vc++、gcc編譯都有,安裝后數個G的體積,但問題是還是會出現這里列出的第 1 條問題,而且那個版本的編譯器不容易配置。

4 這一條不是什么問題,而是在 wxMSW-2.8.12 根目錄,有一個 samples 子目錄,里面存放的是圖形界面的若干個源碼示例,沒錯,需要編譯。在 samples 目錄下也有一個 makefile.gcc,編譯就像編譯庫文件一樣 ,命令行下切換到這下目錄,使用命令 mingw32-make.exe -f makefile.gcc 只是這個 makefile.gcc 是全部編譯 samples 目錄下的所有工程示例(一個子目錄就是一個工程)。

而單個編譯時,要進入相應工程目錄,同樣有 makefile.gcc 文件,操作同上,可能並不是每個都能編譯成功。編譯成功的對應目錄下會有 gcc_mswu 其中有對應的 exe 可執行文件,並拷貝到其它電腦運行一下。

示例 calendar

 

示例 aui

 

 wxWidgets 工程的具體創建過程本文不作敘述。

 

 CodeBlocks 安裝相關參見:http://www.cnblogs.com/hslog/p/hslog0003.html

 文中部分內容可能會有所不同,請以操作為准,如果希望本文更加完善,請告知相關內容,並在此對文中引用的文章的作者表示感謝;

本文可能還會更新...


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM