我有一个程序是以前在Qt4.3.2+Mingw32-3.2.4环境下开发的，其中还加上openssl加密库，编译连接都没问题的。
最近要对它进行一些修改，于是下载了最新的openssl以及Qt4.5,还有和它一起的Mingw32-3.4.5，在改编之前先试一下能否编译。
首先编译openssl，出错，这是以前从未遇到的，出错的原因是连接的时候有几个函数找不到，看了估计是libgdi32里面的，打开有关的MakeFile来看，-lgdi32的参数在啊，然后花了大约半个小时尝试，最后无意中把-lgdi32挪到最后面，成功！心理有一种被耍了的感觉，我记得旧版的Mingw32是没有这种现象的，尝试把-lgdi32往前挪动一下，错误重新出现！
好，编译Qt4.5，安装的时候已经有动态库了，因为想修改后的程序像以前一样用静态库来连接，于是尝试静态编译，好戏开场了，刚才编译openssl的那点错误和后面的情形相比，简直不值一提。
我的Qt安装目录是D:\2009.01\Qt\.....而且QTDIR也正确设置了，可是configure运行就出现qmake.exe报错，找不到"c:\qt-greenhouse\Trolltech\Code_less_create_more......."，奇怪吧，怎么看，我的环境变量设置都是正确的，从来就和这个什么"c:\qt-greenhouse\Trolltech...."挨不上边，都不知道从哪里冒出来的，无奈，想了一个办法：在C盘新建了一个"c:\qt-greenhouse\Trolltech...."目录，利用微软的junction命令将它指向D:\2009.01\qt，总算通过了。
漫长的等待，没出错，把Qt的静态库编译出来了，长长出了一口气，可是没想到，被戏弄的感觉还没结束呢。
开始编译我自己的程序了，这个源码包是以前成功编译过的，把其中MakeFile文件里面的有关目录改一下指向“正确”的地方，把原来连接静态库的参数改为连接动态库，报一大堆错，找不到.h文件，哦，可能指向"D:\2009.01\qt"不行吧，就改为"c:\qt-greenhouse\Trolltech...."试试看，果然编译连接成功，并且可以运行。
好，把MakeFile里面的-lQtCore4 -lQtGui4重新改回-lQtCore -lQtGui，连接静态库，结果出错，又是连接找不到函数，而且出错信息多的要花好几分钟才显示完，再来一次，把输出结果保存为文件，竟有1.86M之大！
典型的出错信息是：undefined reference to `_imp___ZN7QString9fromAsciiEPKci'，全是和Qt有关的，查看了文件夹，libQtCore.a和libQtGui.a这两个文件是存在的，MakeFile里的路径也是对的，傻眼了....我这源码都是以前编译成功的，而且修改MakeFile的办法也是和以前一样的，换了个编译环境就出这种问题。
接着做了不知多少次各种各样的尝试，包括重新把Qt再编译一次，结果还是一样，一整天和半个晚上就这么过去了，几乎要放弃了。
经过分析，Qt4.5的动态库和静态库确实有着奇怪的差异，动态库里面是有`_imp___ZN7QString9fromAsciiEPKci'这样形式的函数的，同时也有`__ZN7QString9fromAsciiEPKci'这样的，而静态库则只有后者的形式，要命的是我编译的.o文件里要求连接的是前者，难道就只能连接动态库？那静态库不就废了？
最后突然想到，试一下给.pro文件里加一行：QMAKE_LFLAGS += -static，qmake一次，发现MakeFile里面仅在LFLAGS =....这行里增加了一个-static，其余都没变化，但是却真的成功了，再看看那些.o文件，里面确实没有了`_imp___ZN7QString9fromAsciiEPKci'这类形式的引用，全变成了`__ZN7QString9fromAsciiEPKci'的形式了，怪不得这回连接成功了，可是我纳闷，.o文件是编译的结果，而不是连接的结果，怎么会受到LFLAGS里面的-static参数的影响呢？LFLAGS不是到连接的时候才有效的吗？
总之，虽然不理解，但是成功编译连接却是事实。
这样的戏弄程序员的行为，估计只有Qt4.5和Mingw32-3.4.5这种梦幻组合才做得出来，以前的Qt和Mingw32版本相比之下严重缺乏幽默感。
不知道下一个版本又是什么样的奇妙组合呢？。
