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

[Oren M. <or...@qu...>]

FYI, while doing development work with C++ under linux, setting your=20
CXXFLAGS to "-g -O0" is probably a good idea.  gcc is an extremely slow=20=

C++ compiler, (though current versions are far better than say 3.04). =20=

This will dramatically improve your build times and reduce memory=20
usage.  No need to notch it up to -O2 unless you are doing performance=20=

testing or are ready to go into production.

--oren

On Aug 23, 2004, at 8:57 AM, James Wiggs wrote:

> QuickFIX Documentation:=20
> http://www.quickfixengine.org/quickfix/doc/html/index.html
> QuickFIX FAQ:=20
> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ
> QuickFIX Support: http://www.quickfixengine.org/services.html
>
> On Mon, 2004-08-23 at 01:57, Joerg Thoennes wrote:
>> Hi James,
>>
>>>    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.
>>
>> I did not use any STLPorts 4.6 package to compile QF, at least I am=20=

>> not
>> aware of it. How is the package name in Debian? Maybe you should try=20=

>> 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.
>>
>> 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.
>>
>> 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.
>
>>>
>>>    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++?
>>
>> At least we do. We had some problems with the JNI part nearly two=20
>> years
>> ago (we are using the Java API), but use QF in production for more=20
>> than
>> a year now. So I guess you are quite unique here.
>>
>> 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
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media
> 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33
> Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift.
> http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285
> _______________________________________________
> Quickfix-developers mailing list
> Qui...@li...
> https://lists.sourceforge.net/lists/listinfo/quickfix-developers
>