On Sat, Mar 22, 2014 at 6:29 PM, Maz Saeed <[hidden email]> wrote:
> Hey Frank,
> One more quick question; where should I start the compilation process? Is it Utility.cpp first and then pretty much any order? My goal is to create all the object files
> first and then convert them into a static library. I guess I could run compilation with VC++ of one of the projects to see in which sequence object files are
> created...thought I'll check with you first.
It doesn't matter at all in what order you compile the .cpp files.
They are independent "translation units" and the .o files that
get produced are independent of one another.
For whatever reason, the first file in my makefile is Session.o
(which causes Session.cpp to get compiled by a make built-in
rule). But it doesn't matter, and I don't recall how my particular
order of files came about.
By the way, which version of QuickFIX are you working with?
Happy QuickFIX Hacking!
> ------- Original Message -------
> From : K. Frank[mailto:]
> Hello Maz!
> On Sat, Mar 22, 2014 at 12:58 PM, Maz Saeed <[hidden email]> wrote:
>> Hey Frank,
>> Getting started on the modifying the quickFix with Windows GCC. As you pointed out to use the UNIX version as a starting point,
>> my question is how do you extract the
>> quickfix-logviewer-1.1.1.tar.gz in Windows environment?
> Hey Frank,
> Starting to compile with MINGW, getting all kinds of errors -- mostly the include related. For starters, do you know where I could find these header files and associated
> #include <sys/socket.h>
> #include <sys/ioctl.h>
> #include <netinet/in.h>
> #include <netinet/tcp.h>
> #include <arpa/inet.h>
> #include <netdb.h>
> #include <fcntl.h>
> #include <unistd.h>
> #include <pthread.h>
> #include <signal.h>
First off, which version of QuickFIX are you working with? And which
version of which compiler?
Are you using a mingw or mingw-w64 version of gcc? If so, which one,
i.e., what is the output of "g++ --version"? Also, do you want a 32-bit
or 64-bit build? (There were a couple of 64-bit incompatibilities I had to
There is an important top-level thing I neglected to mention. To first
approximation, you will want to be using the windows-api code paths
through the ifdef's.
For the most part the windows ifdef-paths are triggered by
The QuickFIX code is a little imperfect in that _MSC_VER typically
indicates that the msvc compiler is being used, while _WIN32
typically indicates that the windows api is being used. These are
two different things, but QuickFIX seems to be using _MSC_VER
for both purposes.
You want to use the windows api (because you will be running on
windows rather than on unix or a unix emulator), but you aren't
using msvc (and I assume that you are using one of the mingw
ports of gcc).
So you will typically have _WIN32 defined (e.g., I believe that
_WIN32 is normally defined automatically by mingw-w64), but
you won't have _MSC_VER defined, because your compiler is
not a version of msvc.
I thought it was cleaner NOT to simply define _MSC_VER
(because it would be incorrect to claim that I was using msvc).
So I chose to change _most_ of the occurrences of _MSC_VER
in the code to _WIN32.
For example, in my copy of Utility.h (I assume that yours is
similar, if not identical.), I have the following #include's:
#ifdef _MSC_VER // <-- change this to _WIN32
#include <Winsock2.h> // <-- these are windows-api headers
typedef int socklen_t;
#include <sys/types.h> // <-- these are posix headers
So if you change _MSC_VER to _WIN32 as indicated above,
you will now be including the windows headers rather than
the posix headers (that you don't have).
There are occurrences of _MSC_VER scattered throughout the
QuickFIX code base. From memory, I changed most, but not
all of these to _WIN32. Just start compiling, and when errors
show up see if _MSC_VER is involved, and if it makes sense,
change it to _WIN32.
Note that the first include file in the windows section is:
This reminds me of something. Not when you compile and "ar"-ing
the static QuickFIX library, but when you link your application to
that library, you will need to specify some libraries in the link
Winsock2.h is for the windows socket implementation that resides
in a library that you will have to link to. At least with mingw-w64, you
do this by specifying
at the end of the link command.
More completely, I had to specify the following libraries:
-lxml2 -lz -liconv -lws2_32
This is because (as mentioned in my earlier posting) I told QuickFIX
to use "LIBXML" rather than "MSXML", and then found a windows
build of libxml. "-lxml2" is for that. "-lz" and "-liconv" are for libraries
used by that libxml implementation.