Re: [Quickfix-developers] Linux Compile Problems - QF1.8.0

[James W. <wi...@wi...>]

On Mon, 2004-08-23 at 01:57, Joerg Thoennes wrote:
> Hi James,
>=20
> >    I eventually gave up and upgraded one of our servers to Debian
> > Sarge; I was able to get it to compile on my Sid workstation, which
> > is running gcc/g++ 3.3.4-7, and Sarge installs with 3.3.4-3, so I
> > figured it was worth a try.  After a few attempts, I was finally
> > able to get it to compile with the STLPorts 4.6 package that comes
> > with Sarge and the MySQL library we have installed.
>=20
> I did not use any STLPorts 4.6 package to compile QF, at least I am not
> aware of it. How is the package name in Debian? Maybe you should try it
> without STLports?

   I will try to do this later this week.  Since I've upgraded
the development server to Sarge, the only machine I have now that
is still running Woody and has enough resources to compile QF is
a production server.  The compile takes more than 12 hours to run
on that box, so I can only attempt it over a weekend.

> > It fails two
> > unit tests, however.  It passes all acceptance tests.
>=20
> All unit and acceptance tests work fine.

   It appears the unit tests that failed were related to MySQL.
I need to build the database tables required for QuickFIX.  This
isn't covered in the current INSTALL documentation.  I'd be happy
to write it up and send it in if you wish.  An added section into
doc/html/install.html just above "Testing QuickFIX" seems logical;
let me know if you want that.

> >    I did not save out the compiler errors I got.  They weren't seg
> > faults or out-of-memory errors.  One as I recall, came back as a
> > floating point exception (?!).  I'm trying to compile it again on
> > one of our other Woody boxes to see if I can get the error for you
> > again.  So far, it's 39 minutes(!) into the compile of Session.cpp,
> > using 384 MB of RAM.  Unbelievable.  Whenever the build dies, I'll
> > send along the error messages.
>=20
> OK, the g++-3.0 is quite slow...

   You ain't kiddin'.  I had to kill it.  It was down to the
compile of the ordermatch Application.cpp file, and had used
95 minutes of CPU time and almost 1.5 GB!!! of memory, so I
had to kill it.  The market was about to open and I couldn't
have one full CPU and 75% of my RAM used by that build.  But
it looks like this machine might make a liar out of me.  It
clearly made it up to building the example apps, and I can
see where the library files were created at 11:28 last night.

   This machine is a dual P3/500 with 2GB of memory, running
Debian Woody, totally stock except that I've upgraded libtools
and the automake tools to Debian sarge to support our use of
Anjuta as a development tool.

> >=20
> >    On a related note, how seriously is Linux *really* supported by
> > the core QuickFIX group?  Having to install a whole new version of
> > the operating system just to get QF to compile doesn't instill a
> > lot of confidence.  I've got a *very* basic application I'm trying
> > to get running with it, and I can't even get a SocketInitiator to
> > instantiate properly.  The code segfaults when I try to do it.  I'm
> > drafting a note on that problem separately.  Am I unique in having
> > so much trouble with QF?  Most of the mailing list messages seem to
> > be from Solaris or Windows developers coding in Java or .NET or VB.
> > How many people are you aware of who are successfully using QF on
> > Linux, coding in C/C++?
>=20
> At least we do. We had some problems with the JNI part nearly two years
> ago (we are using the Java API), but use QF in production for more than
> a year now. So I guess you are quite unique here.
>=20
> Please post more information, esp. which Debian package (version) you
> use to compile QF.

   Build was attempted on a single-CPU Athlon 1GHz with 1.5GB
of RAM.  We tried with both GCC/G++'s from Debian Woody: 2.95.4
and 3.0.4.  STLPort version was 4.5.3, standard install for Woody.
I also downloaded and built STLPort 4.6.2 from source.  No go on
that one either.  Using GLib 2.4.4 on the C side, compiled and
installed from source.  The pthreads library is stock Woody, not
sure of the exact version: 0.9.X.

> Cheers, J=F6rg

   At this point, since I've gotten the code built for our
development work, I'm not so concerned with this problem.  I'd
like to know, ultimately, what's going on, but since we're going
to be upgrading all our servers to Sarge when it is declared the
new stable later this fall, I'm not going to lose much sleep
over it.

   Again, let me know if you want that install documentation on
MySQL configuration.  And thanks again for your replies!

thanks,
Jim Wiggs