在 Windows 下手工搭建各种开发环境都是一件麻烦的事情，下面我要为 Dev-C++ 配置 GTK+ 的开发环境。
- 在 Glade/Gtk+ for Windows 下载开发包，这个是已经编译配置好的安装程序，可以省却不少麻烦。下载一个 gtk-dev-2.12.9-win32-2.exe 就行了。Runtime 好像可以不装。
- 运行以后，会选择配置 IDE 环境，选上 Dev-C++ 即可。
- 这个时候，环境变量以及Dev C++ 的目录设置都应该配置好了。
检查一下环境变量 PATH
%GTK_BASEPATH%\bin
检查一下Dev-C++ 的“工具->编译选项->目录”
- 库：
...\GTK\lib - 包含文件：
...\GTK\include
...\GTK\include\gtk-2.0
...\GTK\include\glib-2.0
...\GTK\include\pango-1.0
...\GTK\include\cairo
...\GTK\include\atk-1.0
...\GTK\include\gtkglext-1.0
...\GTK\include\libglade-2.0
...\GTK\include\libxml2
...\GTK\lib\gtk-2.0\include
...\GTK\lib\glib-2.0\include
...\GTK\lib\gtkglext-1.0\include
这个时候，GTK+ 已经配置好了。
打开 Dev-C++，建立一个新的工程，添加一个新文件：
#include <gtk/gtk.h>
int main(int argc, char *argv[])
{
GtkWidget *window;
gtk_init(&argc, &argv);
window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
gtk_window_set_title(GTK_WINDOW(window), "Hello World");
gtk_widget_show(window);
gtk_main();
return 0 ;
}
这个时候还不能编译，需要修改工程属性，在"工程->工程属性->参数" 或 "工具->编译选项"中的链接器框里面填入：
-lgtk-win32-2.0 -lgdk-win32-2.0 -latk-1.0 -lgdk_pixbuf-2.0
-lpangowin32-1.0 -lgdi32 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0
-lglib-2.0 -lintl -liconv
在编译选项里面填入：
-mms-bitfields
就可以编译通过了。
在运行以后，你会发现出现一个空白窗口，标题为 Hello World。这个时候只点击窗口的关闭是不能结束进程的，你要去任务管理器里面把进程结束。
在工程属性里面，如果把工程类型设置为"Win32
控制台程序"，则运行的时候会同时出现一个控制台窗口（一个黑色的命令行界面的窗口），这个窗口在调试的时候很有用，一些错误信息会在这里显示。如果把工
程类型设置为"Win32 图形界面程序"，这个黑窗口就没有了。
为什么要在编译选项里面加入"-mms-bitfields"？下面照抄网上找来的解释：
CPU访问内存时，总是以其整数字长为单位读写。比如 x86 CPU
总是从4字节的整数倍数地址上，读取4字节数据，它不能随心所欲地从任何位置开始读取任意长度数据。为了效率考虑，默认情况下编译器总是让整数存放于其长
度的整数倍数地址上。在一个结构中，为了做到这一点，有时不得不浪费几个字节。
举个例子，我们定义一个结构：
struct {
char c;
int i;
};
从字面上看，这个结构的长度是5个字节，但默认情况下编译器总是分配8个字节，是为了让 i 出现在偏移量 4 地址上。
位域 bitfields 是 C 语言结构中的一个成员，可以指定该成员所占内存的位数 bit。然而，在位域的对齐方式上，GCC和MSVC这2个编译器产生了巨大的分歧。现在，我们将上面这个结构改成下面这样子：
struct {
char c;
int b: 1;
int i;
};
我们在 c 和 i 中插入了一个只占 1 位内存的整数。在 GCC 中，我们测试该结构的长度，发现仍然是 8 个字节，就是说 b
利用了 c 和 i 间的空隙，而没有多占空间。然而在 VC 中我们会发现，结构长达 12 字节。也就是说 b
像其他所有整数一样，在4倍数地址上对齐了。
如果仅仅这样还好办，不幸的是，如果你在b后面再插入一个位域 b2，长度还是12。而如果插入一个 short 型的位域，长度将变成16！
其原因在于 VC 使用了一种古怪的对齐方式，且没有完整的文档描述。基本上，VC
将结构中相邻的相同数据结构位域组成位域组，然后每个位域组都默认要求按其数据类型对齐。另外还有许多不同的例外情况。这样的情况与任何一个普通
GCC 支持的 对齐模式都不同。对齐方式不同意味着什么呢？考虑一下，Windows 是用 VC 编译的，也就是说所有 Windows API
都使用 VC 对齐方式。而如果你用 MinGW GCC编译 Windows 程序，你对所有使用了位域的 Windows API
的调用都将出错！而我们的 GTK+ for Windows 显然也是使用了这种对齐方式。
万幸的是，Windows 版 GCC 在编译时补上了一个新的命令行开关，-mms-bitfields，使其使用 VC 兼容的对齐方式。而这个开关别的平台上的 gcc 则都没有。加上这个编译开关后生成的代码将与 VC 的代码有相同的行为特征。
点击此处查看原文 >>
系统分类:
软件开发 | 用户分类:
无分类
| 来源:
无分类