Last Updated: January 18, 2006
WCC allows the visual studio compiler and the Intel compiler for windows to be used as if they were unix cc style compilers. The primary purpose of WCC is for use with Msys. WCC takes options like -c, -o, -I, -l, ext, and then calls the native windows compiler with the appropriate options. There are a few other things that go on beyond just translating command line parameters such as being able to search for dll's in a similar manor to .so's on unix. An ar wrapper for lib.exe is also included. WCC is also open source and freely distributable.
WCC is implemented as a C program that simply uses system() to run the native compiler. This was done instead of a shell script because:
First install Visual Studio, and make sure it works (I'm using VS 2003). Then install Msys. You can still optionally install mingw, it will not conflict with wcc. Download the wcc source. Now enter the VS build environment shell window. Change into the msys directory, ie cd c:\msys\1.0\ . From there run msys.bat. You should now be in a msys shell inside a rxvt window. You will now be able to use the Visual Studio command line tools from inside msys. Verify that you can run cl for example. Note that in the msys shell "\" is the escape character so if you want a real "\" you must use "\\". For example cl \\? for what would be cl \? in the windows shell. Also note that most of the time you can give windows programs file paths with "/", instead of "\" - ie cl ../path/to/my/source.c is valid. I recommend making new short cut to a modified copy of vcvars.bat program that goes strait into this visual studio + msys setup since any time you wish to use wcc you will need to recreate this environment.
Now untar the wcc files. Optionally edit the #define line in the file wcc.c to reflect a different path for the real compiler. To build just run cl wcc.c to produce the executable wcc.exe. You might want to rename it to something like wcc-intel if you are going to use multiple versions on your system at the same time. You should be able to place the binary anywhere in your path, but for some reason I find that unless it goes in the same directory as Visual Studio's cl.exe none of of the command line parameters get passed to it (can anyone explain this?). Verify that you can run wcc or whatever it was you renamed it to.
-!, --wraper_test This will cause wcc to simply print the command it is going to use to call the native compiler with and exit, instead of actually doing anything. This useful when things go wrong, or when unsure what wcc will do in a situation.
--pre arg, --post arg This will pass arg unchanged before or after the other parameters on the native compiler's command line.
--help, -? Quick usage cheat sheet. (not always up to date)
Default Output Normally cl myprog.cpp would produce myprog.exe. I found this to really confuse configure scripts. So now, like MinGW, wcc myprog.cpp produces a.exe. CL in this situation also leaves an unlinked object file, myprog.obj, in the current directory. With MinGW we only want this if we were using -c. Therefor, wcc will remove any created .obj from the current directory before returning unless the -c option is used. It will not just blindly delete obj files that just happen to be in the directory though.
Input object file names CL only recognizes .obj files as object files for input. If you pass a .o file to wcc, a temporary copy will be made with the .obj extension. The copied file will be passed to cl, then deleted before wcc exits.
Standard Options-o output_file_name CL has different options to adjust the output name for different kinds of output. WCC will produce the expected gcc style behavior.
-c Compiles with out linking - realized with cl's /c option.
-Dtoken, -Utoken Define and undefine the preprocessor token from the command line - realized with cl's /D and /U.
-I dir Add a directory to the list of directories that are search for header files - realized with cl's /I.
-E Only preprocess and output to stdout - realized with cl's /E. (needed to make configure work)
-L dir Add dir to the list of directories to look for .dll and .lib files - see below.
-llibrary For each directory given with -L, each directory listed in the environment variable LIB, and in certain hard coded paths (currently just "C:/WINDOWS/System32/"), the file for library is attempted to be found using the following combinations in this order: liblibrary.lib, and library.lib. Once the real file is found, its full path is supplied to cl as an input file.
-static Requests static linkage only. This doesn't do anything right now.
-shared Builds a dll.
-Wllinker_option=value,linker_option=value This should work the same way MinGW does. It quietly does nothing now.
-g
-fpic Quietly does nothing. This is so wcc can build object files for use in dlls as gcc would for shared libraries.
-O2 Realized with cl's /O2.
-Wall Realized with cl's /Wall.
-w Realized with cl's /w.
-mcpu=cpu_type Optimize for a specific type. Accepted values: athlon, pentium4 (both of which end up being /G7).
To tell a configure script to use wcc instead of mingw use CC=wcc ./configure. At this point wcc will at least work with the AC_PROG_CC macro, as well as AC_CHECK_HEADERS().
There are no doubt numerious differences between visual studio and gcc / MinGW. Here are a few that I have noticed so far. Please let me know of any other common ones you find.
Local variable declaration If you place any code before declaring local function variables in a function, cl does not like that.
Including winsock.h The real windows.h includes winsock2.h, so explicitly including winsock2.h as with mingw causes errors. The solution for a source file compatable with mingw and visual studio is to #define WIN32_LEAN_AND_MEAN before the include of windows.h.
Direct DLL linking MinGW can (sometimes) link directly to .dll files, while cl requires you to link with the dll's corrisponding .lib. This area to me still seems fuzy.
Copyright (c) 2006, Thomas Stover All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.