Thread: RE: [Quickfix-developers] Solaris compile problems
Brought to you by:
orenmnero
From: Peterson, K. <kri...@rb...> - 2004-08-18 07:55:52
|
Tim, Your problem is that you are linking libstdc++.so twice. G++ already links = in libstdc++.so, so there is no reason to explicitly mention it on the comm= and line. Remove the /usr/local/lib/libstdc++.so file and it will link. The= /usr2/SOURCES8/S8/gcc-3.4.1/* and /usr/local/sparc-sun-solaris2.8/* librar= y search paths don't need to be there either as these are g++ specific dire= ctories that g++ will search as necessary. I had similar libtool problems on Solaris with both g++ and SunPRO. After u= ntar'ing QuickFIX source but before running configure, I run a script that = clean up Makefile.in, configure and Makefile files throughout the tree remo= ving the '-lstdc++' which appears in these files. Running configure and mak= e then works without a problem. This isn't the whole solution as Solaris/g++ builds still include directori= es from the g++'s source tree. From what I could see, as g++ uses libtool t= o build itself and installs *.la files pointing back to g++'s build area. W= hen QuickFIX builds, it's libtool sees the *.la files of libstdc++ and thus= adds unnecessary rubbish to the link command line. Here's part of my post-untar script for QuickFIX, it should give you an ide= a of what needs to be done. - Kris # Substitutable template for a command that generates an ed script GED_ED_SCRIPT=3D"printf ',s/ \$R//g\\\\n,s/\$R //g\\\\n,s/\$R//g\\\= \nw'" # Remove any carriage returns from C/C++ source files # Really should fix up Java files as well but they all have CRs, # java tools can handle them, we don't need to patch them and don't # we don't need to edit them CR=3D`printf '\r'` find $QF_DIR \( -name '*.h' -o -name '*.c' -o -name '*.cpp' \) | \ $XARGS grep -l "$CR" | $XARGS -ti dos2unix {} {} # Remove -lstdc++, not needed and breaks both Forte and GCC builds R=3D'-lstdc++' eval ED_SCRIPT_CMD=3D\"$GED_ED_SCRIPT\" find $QF_DIR \( -name Makefile -o -name Makefile.in -o -name config= ure \) -exec \ sh -c "set \`$ED_SCRIPT_CMD | ed \$0 | sed -n '1h;\$G;\$s/\= n/ /;\$p'\`; [ "\$1" -ne "\$2" ] && ech$ # Patch to clean up test programs, FIX constants and other miscella= neous bits (cd $QF_DIR && $PATCH -p1 < $QF_PATCH1) || exit 1 (cd $QF_DIR && $PATCH -p1 < $QF_PATCH2) || exit 1 (cd $QF_DIR && $PATCH -p1 < $QF_PATCH3) || exit 1 (cd $QF_DIR && $PATCH -p1 < $QF_PATCH4) || exit 1 # Remove -Wall flags if building with SUN PRO if [ "$MODE" =3D=3D "forte" -o "$MODE" =3D=3D "rwforte" ]; then R=3D'-Wall' eval ED_SCRIPT_CMD=3D\"$GED_ED_SCRIPT\" find $QF_DIR \( -name Makefile -o -name Makefile.in -o -na= me configure \) -exec \ sh -c "set \`$ED_SCRIPT_CMD | ed \$0 | sed -n '1h;\$G;\$s/\= n/ /;\$p'\`; [ "\$1" -ne "\$2" ] && ech$ # Patches for Forte (cd $QF_DIR && $PATCH -p1 < $QF_SUNPRO_PATCH1) || exit 1 (cd $QF_DIR && $PATCH -p1 < $QF_SUNPRO_PATCH2) || exit 1 (cd $QF_DIR && $PATCH -p1 < $QF_SUNPRO_PATCH3) || exit 1 fi fi -----Original Message----- From: qui...@li... [mailto:qui...@li...]On Behalf Of Tim Feeney Sent: 17 August 2004 19:12 To: qui...@li... Subject: [Quickfix-developers] Solaris compile problems QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/ind= ex.html QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ QuickFIX Support: http://www.quickfixengine.org/services.html I tried to send this question to the users list but it was bounced back. I have a Solaris 2.8 machine that I am trying to compile quickfix on. Here is the setup gcc - 3.4.1 automake - 1.8.4 libtool - 1.5 autoconf - 2.59 libxml2 - 2.6.9 m4 - 1.4.1 I have an older version from a Mac that is running quickfix that fails to compile giving me an error: configure.in:14: /usr/local/bin/m4: ERROR: Reading inserted file: No such file or directory If I run bootstrap first on this build it also gives the same error. I downloaded the latest version to see if that was the problem but this does not compile either. I get configure to run through with no problems but when I then run make I get: g++ -g -O2 -Wall -I/usr/local/include/libxml2 -I/include -I/include/solaris -o .libs/at at.o C++/.libs/libquickfix.so -L/usr/local/lib -L/usr/lib -L/usr/openwin/lib -L/usr/local/ssl/lib /usr/local/lib/libstdc++.so -L/usr2/SOURCES/S8/gcc-3.4.1/objdir/sparc-sun-solaris2.8/libstdc++-v3/=20 src -L/usr2/SOURCES/S8/gcc-3.4.1/objdir/sparc-sun-solaris2.8/libstdc++-v3/=20 src/.libs -L/usr2/SOURCES/S8/gcc-3.4.1/objdir/gcc -L/usr/local/sparc-sun-solaris2.8/bin -L/usr/local/sparc-sun-solaris2.8/lib -L/usr/local/lib/../sparc-sun-solaris2.8/lib /usr/local/lib/libxml2.so -lz -lpthread /usr/local/lib/libiconv.so -lm -lsocket -lnsl -liberty -Wl,-R -Wl,/usr/local/lib ld: warning: file /usr/local/lib/libstdc++.so: attempted multiple inclusion of file If I run bootstrap I get the same message with regards to configure.in. I don't see anything in the list archives, so any hints/help from people that have gotten this to work? Tim ------------------------------------------------------- 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 <font face=3D"Times New Roman" size=3D"3"> <p>------------------------------------------------------------------------= ------</p> <p> This email is intended only for the use of the individual(s) to whom it= is addressed and may be privileged and confidential. Unauthorised use or d= isclosure is prohibited. If you receive this e-mail in error, please advise= immediately and delete the original message. This message may have been al= tered without your or our knowledge and the sender does not accept any liab= ility for any errors or omissions in the message.</p> <p>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D</p> </font> |
From: Tim F. <ti...@fi...> - 2004-08-20 18:38:34
|
Oren and Kristofer thanks for the help. I have gotten past all the lib problems but am now stuck on another issue. When I do the make it fails with the following: make[3]: Entering directory `/home/tim/quickfix/src' if g++ -DHAVE_CONFIG_H -I. -I. -I.. -IC++ -I/usr/include -I/usr/ccs/include -Wall -I/usr/local/include/libxml2 -I/include -I/include/solaris -MT at.o -MD -MP -MF ".deps/at.Tpo" -c -o at.o at.cpp; \ then mv -f ".deps/at.Tpo" ".deps/at.Po"; else rm -f ".deps/at.Tpo"; exit 1; fi /bin/bash ../libtool --mode=link g++ -I/usr/include -I/usr/ccs/include -Wall -I/usr/local/include/libxml2 -I/include -I/include/solaris -o at at.o C++/libquickfix.la -lpthread -L/usr/local/lib -R/usr/local/lib -lxml2 -lz -lpthread -liconv -lm -lsocket -lnsl -liberty mkdir .libs g++ -I/usr/include -I/usr/ccs/include -Wall -I/usr/local/include/libxml2 -I/include -I/include/solaris -o at at.o C++/.libs/libquickfix.a -lpthread -L/usr/local/lib -lxml2 -lz -lpthread -liconv -lm -lsocket -lnsl -liberty -lpthread -L/usr/local/lib -lxml2 -lz -lpthread -liconv -lm -lsocket -lnsl -liberty -R/usr/local/lib -R/usr/local/lib Undefined first referenced symbol in file nanosleep C++/.libs/libquickfix.a(Utility.o) ld: fatal: Symbol referencing errors. No output written to at collect2: ld returned 1 exit status make[3]: *** [at] Error 1 make[3]: Leaving directory `/home/tim/quickfix/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/tim/quickfix/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/tim/quickfix' make: *** [all] Error 2 I have tried to figure this out even explicitly doing a #include "/usr/include/time.h" but no luck. Any help? I did delete and create a new quickfix install, made the necessary changes, installed libtool1.3.5, and ran configure with the --disable-shared option. Still no go. -- Timothy J. Feeney Financial Labs LLC Phone: (617) 354-0185 -- Timothy J. Feeney Financial Labs LLC Phone: (617) 354-0185 |
From: Oren M. <or...@qu...> - 2004-08-20 19:04:04
|
Oh, yeah, I believe nanosleep is located in the rt library. Try adding a -lrt --oren On Aug 20, 2004, at 1:40 PM, Tim Feeney wrote: > QuickFIX Documentation: > http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: > http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > Oren and Kristofer thanks for the help. > > I have gotten past all the lib problems but am now > stuck on another issue. When I do the make it fails with the > following: > make[3]: Entering directory `/home/tim/quickfix/src' > if g++ -DHAVE_CONFIG_H -I. -I. -I.. -IC++ -I/usr/include > -I/usr/ccs/include -Wall -I/usr/local/include/libxml2 -I/include > -I/include/solaris -MT at.o -MD -MP -MF ".deps/at.Tpo" -c -o at.o > at.cpp; \ > then mv -f ".deps/at.Tpo" ".deps/at.Po"; else rm -f ".deps/at.Tpo"; > exit > 1; fi > /bin/bash ../libtool --mode=link g++ -I/usr/include -I/usr/ccs/include > -Wall -I/usr/local/include/libxml2 -I/include -I/include/solaris > -o > at at.o C++/libquickfix.la -lpthread -L/usr/local/lib > -R/usr/local/lib -lxml2 -lz -lpthread -liconv -lm -lsocket -lnsl > -liberty > mkdir .libs > g++ -I/usr/include -I/usr/ccs/include -Wall > -I/usr/local/include/libxml2 > -I/include -I/include/solaris -o at at.o C++/.libs/libquickfix.a > -lpthread -L/usr/local/lib -lxml2 -lz -lpthread -liconv -lm -lsocket > -lnsl -liberty -lpthread -L/usr/local/lib -lxml2 -lz -lpthread -liconv > -lm -lsocket -lnsl -liberty -R/usr/local/lib -R/usr/local/lib > Undefined first referenced > symbol in file > nanosleep C++/.libs/libquickfix.a(Utility.o) > ld: fatal: Symbol referencing errors. No output written to at > collect2: ld returned 1 exit status > make[3]: *** [at] Error 1 > make[3]: Leaving directory `/home/tim/quickfix/src' > make[2]: *** [all-recursive] Error 1 > make[2]: Leaving directory `/home/tim/quickfix/src' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/home/tim/quickfix' > make: *** [all] Error 2 > > I have tried to figure this out even explicitly doing a #include > "/usr/include/time.h" but no luck. Any help? > > I did delete and create a new quickfix install, made the necessary > changes, installed libtool1.3.5, and ran configure with the > --disable-shared option. Still no go. > > -- Timothy J. Feeney Financial Labs LLC Phone: (617) 354-0185 > > -- > Timothy J. Feeney > Financial Labs LLC > Phone: (617) 354-0185 > > > > > > ------------------------------------------------------- > 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 > |
From: James W. <wi...@wi...> - 2004-08-21 15:45:47
|
Hello, I am attempting to build QuickFIX 1.8.0 on a Linux box, Debian Stable, fully up-to-date. I have installed the latest stable version of STLPort. I get compiler errors when compiling with either gcc 2.95 or gcc 3.04, the only two stock compilers available for Debian stable. I am willing to upgrade the machine to Debian Sarge, which will be the new stable within a few months, but do *not* want to go down that road if it won't solve the problem. I am testing a build on one of our workstations, which run Debian unstable (i.e. SID). The compile has not completed yet, but if it does, I'll at least know that gcc 3.3.4 will work. So, the question: what versions of GCC have been used successfully to build 1.8.0 on a Linux machine? The errors I've been getting are actual internal compiler errors, complete with a request to send a bug report to GNU, not library or linking errors. Neither are they out of memory errors; there's plenty of RAM on the box. thanks, Jim Wiggs |
From: Joerg T. <Joe...@ma...> - 2004-08-22 21:04:06
|
Hi James, > I am attempting to build QuickFIX 1.8.0 on a Linux box, Debian > Stable, fully up-to-date. I have installed the latest stable version > of STLPort. I get compiler errors when compiling with either gcc 2.95 > or gcc 3.04, the only two stock compilers available for Debian stable. > I am willing to upgrade the machine to Debian Sarge, which will be the > new stable within a few months, but do *not* want to go down that road > if it won't solve the problem. I am testing a build on one of our > workstations, which run Debian unstable (i.e. SID). The compile has > not completed yet, but if it does, I'll at least know that gcc 3.3.4 > will work. > > So, the question: what versions of GCC have been used successfully > to build 1.8.0 on a Linux machine? The errors I've been getting are > actual internal compiler errors, complete with a request to send a bug > report to GNU, not library or linking errors. Neither are they out of > memory errors; there's plenty of RAM on the box. I did compile 1.8.0 both on Debian stable (woody) and testing (sarge) without any problems. Which kind of problems do you have? Cheers, Jörg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
From: James W. <wi...@wi...> - 2004-08-23 00:49:28
|
Hello Joerg, Many thanks for the reply! On Sun, 2004-08-22 at 17:03, Joerg Thoennes wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/i= ndex.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html >=20 > Hi James, >=20 > > I am attempting to build QuickFIX 1.8.0 on a Linux box, Debian > > Stable, fully up-to-date. I have installed the latest stable version > > of STLPort. I get compiler errors when compiling with either gcc 2.95 > > or gcc 3.04, the only two stock compilers available for Debian stable. > > I am willing to upgrade the machine to Debian Sarge, which will be the > > new stable within a few months, but do *not* want to go down that road > > if it won't solve the problem. I am testing a build on one of our > > workstations, which run Debian unstable (i.e. SID). The compile has > > not completed yet, but if it does, I'll at least know that gcc 3.3.4 > > will work. > >=20 > > So, the question: what versions of GCC have been used successfully > > to build 1.8.0 on a Linux machine? The errors I've been getting are > > actual internal compiler errors, complete with a request to send a bug > > report to GNU, not library or linking errors. Neither are they out of > > memory errors; there's plenty of RAM on the box. >=20 > I did compile 1.8.0 both on Debian stable (woody) and testing (sarge)=20 > without any problems. Which kind of problems do you have? >=20 > Cheers, J=F6rg 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. It fails two unit tests, however. It passes all acceptance tests. 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. 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++? thanks, Jim Wiggs |
From: Joerg T. <Joe...@ma...> - 2004-08-23 05:57:25
|
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 not aware of it. How is the package name in Debian? Maybe you should try it without STLports? > It fails two > unit tests, however. It passes all acceptance tests. All unit and acceptance tests work fine. > 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... > > 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 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. Please post more information, esp. which Debian package (version) you use to compile QF. Cheers, Jörg -- Joerg Thoennes http://macd.com Tel.: +49 (0)241 44597-24 Macdonald Associates GmbH Fax : +49 (0)241 44597-10 Lothringer Str. 52, D-52070 Aachen |
From: Oren M. <or...@qu...> - 2004-08-23 06:13:11
|
On this, he doesn't mention, but my guess would be these are the MySQL unit tests. If you do not build the quickfix database, then yes, these two tests will fail. >> It fails two >> unit tests, however. It passes all acceptance tests. > > All unit and acceptance tests work fine. |
From: James W. <wi...@wi...> - 2004-08-23 13:57:25
|
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 |
From: Oren M. <or...@qu...> - 2004-08-23 15:01:09
|
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 > |
From: James W. <wi...@wi...> - 2004-08-23 15:15:08
|
Oren, I will keep this in mind for the next time I build it (hopefully not for a few days, at least). I'm getting the MySQL database in place for use. I can't find in the unit tests where to set the username and password to use when connecting, though. Where should that go? Environment variable? No documentation I can find on this... best, Jim On Mon, 2004-08-23 at 11:00, Oren Miller wrote: > QuickFIX Documentation: http://www.quickfixengine.org/quickfix/doc/html/index.html > QuickFIX FAQ: http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ > QuickFIX Support: http://www.quickfixengine.org/services.html > > FYI, while doing development work with C++ under linux, setting your > CXXFLAGS to "-g -O0" is probably a good idea. gcc is an extremely slow > C++ compiler, (though current versions are far better than say 3.04). > This will dramatically improve your build times and reduce memory > usage. No need to notch it up to -O2 unless you are doing performance > testing or are ready to go into production. > > --oren > |
From: Oren M. <or...@qu...> - 2004-08-23 15:23:19
|
The MySQLStoreFactory uses the default settings if nothing is passed into the constructor. Either pass in your settings to the constructor for the test object, or change the default settings in MySQLStore.cpp --oren On Aug 23, 2004, at 10:14 AM, James Wiggs wrote: > > Oren, > > I will keep this in mind for the next time I build it > (hopefully not for a few days, at least). I'm getting the > MySQL database in place for use. I can't find in the unit > tests where to set the username and password to use when > connecting, though. Where should that go? Environment > variable? No documentation I can find on this... > > best, > Jim > > On Mon, 2004-08-23 at 11:00, Oren Miller wrote: >> QuickFIX Documentation: >> http://www.quickfixengine.org/quickfix/doc/html/index.html >> QuickFIX FAQ: >> http://www.quickfixengine.org/wikifix/index.php?QuickFixFAQ >> QuickFIX Support: http://www.quickfixengine.org/services.html >> >> FYI, while doing development work with C++ under linux, setting your >> CXXFLAGS to "-g -O0" is probably a good idea. gcc is an extremely >> slow >> C++ compiler, (though current versions are far better than say 3.04). >> This will dramatically improve your build times and reduce memory >> usage. No need to notch it up to -O2 unless you are doing performance >> testing or are ready to go into production. >> >> --oren >> > > > |