I suspect that I'm the first person to have ever attempted to build the TigerVNC Windows components on an actual Windows machine using MinGW, so I thought I'd share my experience thus far.
I already have a MinGW build environment that I use to build libjpeg-turbo, so the first thing I tried was using that environment. My build environment uses the stock MSYS 1.0.11 and MSYS Developer Toolkit (DTK) 1.0.1 distributions, both installed from the .exe's provided by the MinGW project. I don't use the provided installer .exe for MinGW, because it contains an older version of GCC (3.4.5). libjpeg-turbo needs GCC >= 4.1 for best performance, so I use an updated toolchain based on GCC 4.4.0. The MinGW installer .exe is no longer being supported by the MinGW Project. They are supposedly working on a new apt-get-like mechanism, but until they get this online, it is necessary to install the more recent toolchains by hand. Specifically, the components necessary to run the GCC 4.4.0 toolchain are: binutils-2.20-1-mingw32-bin.tar.gz gcc-c++-4.4.0-mingw32-bin.tar.gz gcc-c++-4.4.0-mingw32-dll.tar.gz gcc-core-4.4.0-mingw32-bin.tar.gz gcc-core-4.4.0-mingw32-dll.tar.gz gmp-4.2.4-mingw32-dll.tar.gz mingwrt-3.17-mingw32-dev.tar.gz mingwrt-3.17-mingw32-dll.tar.gz mpfr-2.4.1-mingw32-dll.tar.gz w32api-3.14-mingw32-dev.tar.gz (NOTE: you can add http://prdownloads.sf.net/mingw/ in front of any of the components in this list or any of the other lists below to download the component directly.) The first problem I ran into was that the MSYS DTK installs autoconf and automake but not autopoint (which is part of gettext.) gettext is available as a separate tarball, but the version provided in the tarball is not compatible with the older autotools provided in the MSYS DTK installer. Thus, I had to uninstall the MSYS DTK and install the following updated DTK components manually: autoconf-2.65-1-msys-1.0.13-bin.tar.lzma automake-1.11.1-1-msys-1.0.13-bin.tar.lzma cvs-1.12.13-1-msys-1.0.11-bin.tar.lzma gettext-0.17-1-msys-1.0.11-bin.tar.lzma gettext-0.17-1-msys-1.0.11-dev.tar.lzma libcrypt-1.1_1-3-msys-1.0.13-dll-0.tar.lzma libtool-2.2.7a-2-msys-1.0.13-bin.tar.lzma m4-1.4.13-1-msys-1.0.11-bin.tar.lzma perl-5.6.1_2-2-msys-1.0.13-bin.tar.lzma This allowed me to successfully autoreconf the source. Now I tried building it. The build ran almost through to completion but failed when linking vncviewer. After much googling, the failure was discovered to be caused by an error in C:\mingw\lib\gcc\mingw32\4.4.0\libstdc++.la. Line 11 points to the DLL version of libstdc++, not the static version, but the DLL version of libstdc++ is not included in any of the GCC 4.4.0 toolchain packages (that is a known issue for this toolchain.) I edited the offending line to read library_names='libstdc++_s.a' Huzzah. Successfully built and ran vncviewer, but not winvnc because of the afore-mentioned CLSID_ActiveDesktop issue. In the interest of attempting to find an easier procedure for other developers, I then tried using the stock GCC 3.4.5 toolchain installed by the MinGW integrated installer (MinGW-5.1.6.exe.) This built vncviewer with no problems, but of course the performance of the resulting executable was reduced. I then tried the most recent toolchain, GCC 4.5.0, which can be downloaded using the mingwdl.sh script found here: http://www.mingw.org/wiki/HOWTO_Install_the_MinGW_GCC_Compiler_Suite The GCC 4.5.0 packages include the libstdc++ DLL as well as a compiler switch to force the use of the static version of libstdc++. When using this toolchain, I got some weird linker errors when trying to link vncviewer: Info: resolving vtable for __cxxabiv1::__vmi_class_type_info by linking to __imp___ZTVN10__cxxabiv121__vmi_class_type_infoE (auto-import) Info: resolving vtable for __cxxabiv1::__si_class_type_info by linking to __imp___ZTVN10__cxxabiv120__si_class_type_infoE (auto-import) Info: resolving vtable for __cxxabiv1::__class_type_info by linking to __imp___ZTVN10__cxxabiv117__class_type_infoE (auto-import) c:/mingw/bin/../lib/gcc/mingw32/4.5.0/../../../../mingw32/bin/ld.exe: warning: auto-importing has been activated without --enable-auto-import specified on the command line. Then when I actually tried to run vncviewer, I got an error dialog: "The application failed to initialize properly (0xc0000005)." Ugh. Additionally, it's worthy of note that autotools is tortuously slow on Windows. It takes something like 20 minutes to configure and build just vncviewer. So, the basic problems are as follows: (1) Only a very specific MinGW toolchain can be made to work with our build, and even that requires some tweaking (editing libstdc++.la.) (2) This allows only a subset of the Windows components to be built. (3) The toolchain is a pain to install. (4) The performance of the toolchain is unacceptable. I understand everyone's general aversion to Visual C++ and the desire to have an integrated build system, but it also seems really bad that the only viable way to build the Windows code is by using Linux. In terms of best practices, I don't see any other big open source code bases using autotools and MinGW to produce Windows executables. I now know why. DRC ------------------------------------------------------------------------------ _______________________________________________ Tigervnc-devel mailing list Tigervnc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/tigervnc-devel
