quickfix-developers

[Quickfix-developers] Build problems on Solaris

[Bishop, B. <Bar...@gs...>]

Hi,

I've been developing an application using quickfix 1.3.2 and java running on
solaris. I never managed to get the build working correctly and resorted to
compiling every source file and linking them into one huge shared object
library.

Everything seemed to be fine all the way through development and testing
until the application was released in to production whereupon it failed
after a few seconds with a 'Problem has occured in a thread outside the
JVM...' error.

The production machine is a very fast dual processor sun box and the
application failed on the initial download of SecurityStatus messages which
proceeds very quickly until the crash.

Is there a known problem using quickfix on a multi-processor machine?

I noticed that quickfix 1.4.0 contains a fix for a 'race condition' and so
decided to give it a go.

However, even though I managed to get configure to work (without the libxml
test) the build still doesn't give me a working shared object library. It
warns me when linking libquickfix_jni.so that it has not linked to
libquickfix as a shared version is not available. Is it possible to make a
shared version of this library?

Sure enough, the library fails to load in to the JVM.

I've resorted to using my old build script which worked with quickfix 1.3.2,
but this leads relocation errors at load time (__eh_alloc or
__builtin_vec_new or others depending on my tweaks to my build script).

I'm pretty desperate now as I've missed a deadline and I have no idea how to
get a working library built.

I'm not interested in keeping the binaries small or even efficiency. If
someone could tell me a simple way to build one gigantic binary linked with
everything I'll need I would be most grateful. Surely it can't be that
difficult. Ultimately, all we have are two directories of C++ source files
that need to be compiled and linked.

I've included both my scripts for building the two versions of quickfix I
have.

Many beers are available for the person who can help. :-)

Regards,
barry



*********************************************************
This is the script I used to build 1.4.0
*********************************************************
#!/bin/ksh
gcc=/opt/gnu/bin/gcc


# INCLUDE
JSEI=/opt/JDK-1.3/j2se/include
JSES=/opt/JDK-1.3/j2se/include/solaris

GCC1=/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95/2/include
GCC2=/opt/gnu/include/g++-3

QUICKFIX_I1=~
QUICKFIX_I2=~/quickfix
QUICKFIX_I3=~/quickfix/src/C++

LIBXML_I=/home/bishoba/libxml2-2.4.25/include

# LIBS
QUICKFIX_L=~/quickfix/lib


LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$QUICKFIX_L

LIBS='-lsocket -lnsl -lthread -lelf'
MORELIBS='-lquickfix -lxml2'


gcc -save-temps -G -o libquickfix_jni.so -fexceptions -finline-functions
../java/*.cpp ../C++/*.cpp    -lgcc -lstdc++ -lpthread -lxml2 -liberty -lz
-D_XOPEN_SOURCE=500 -lnsl -I$JSEI -I$JSES -I$GCC1 -I$GCC2 -I$QUICKFIX_I1
-I$QUICKFIX_I2 -I$QUICKFIX_I3 -I$LIBXML_I -I../../.. -I../../../include -I
/home/bishoba  -L/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/  -lsocket




*********************************************************
This is the script I used to build 1.3.2
*********************************************************
#!/bin/ksh
gcc=/opt/gnu/bin/gcc


# INCLUDE
JSEI=/opt/JDK-1.3/j2se/include
JSES=/opt/JDK-1.3/j2se/include/solaris

GCC1=/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95/2/include
GCC2=/opt/gnu/include/g++-3

QUICKFIX_I1=~
QUICKFIX_I2=~/quickfix
QUICKFIX_I3=~/quickfix/src/C++

LIBXML_I=/home/bishoba/libxml2-2.4.25/include

# LIBS
LIBS='-lsocket -lnsl -lthread -lelf'
MORELIBS='-lquickfix -lxml2'


gcc -G -o libquickfix_jni.so -fexceptions -finline-functions  ../C++/*.cpp
../java/*.cpp -lgcc -lstdc++ -lpthread -lxml2 -liberty -lz
-D_XOPEN_SOURCE=500 -lnsl -I$JSEI -I$JSES -I$GCC1 -I$GCC2 -I$QUICKFIX_I1
-I$QUICKFIX_I2 -I$QUICKFIX_I3 -I$LIBXML_I -I../../.. -I../../../include -I
/home/bishoba  -L/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/  -lsocket

Re: [Quickfix-developers] Build problems on Solaris

[Oren M. <ore...@ya...>]

There is indeed a known problem with using quickfix on a multiprocessor machine.
This is actually a bug with the implementation of STL that is distributed with some versions of gcc.  The easiest way to fix this is to install STLPort and configure quickfix with the --stlport option. (or if not using the configure script, put it in your include path)
I have encountered the problem you have seen with creating the shared library as well.  I can go over some steps you can take for that, but you should probably try building 1.3.2 with stlport first.
 "Bishop, Barry" <Bar...@gs...> wrote:Hi,

I've been developing an application using quickfix 1.3.2 and java running on
solaris. I never managed to get the build working correctly and resorted to
compiling every source file and linking them into one huge shared object
library.

Everything seemed to be fine all the way through development and testing
until the application was released in to production whereupon it failed
after a few seconds with a 'Problem has occured in a thread outside the
JVM...' error.

The production machine is a very fast dual processor sun box and the
application failed on the initial download of SecurityStatus messages which
proceeds very quickly until the crash.

Is there a known problem using quickfix on a multi-processor machine?

I noticed that quickfix 1.4.0 contains a fix for a 'race condition' and so
decided to give it a go.

However, even though I managed to get configure to work (without the libxml
test) the build still doesn't give me a working shared object library. It
warns me when linking libquickfix_jni.so that it has not linked to
libquickfix as a shared version is not available. Is it possible to make a
shared version of this library?

Sure enough, the library fails to load in to the JVM.

I've resorted to using my old build script which worked with quickfix 1.3.2,
but this leads relocation errors at load time (__eh_alloc or
__builtin_vec_new or others depending on my tweaks to my build script).

I'm pretty desperate now as I've missed a deadline and I have no idea how to
get a working library built.

I'm not interested in keeping the binaries small or even efficiency. If
someone could tell me a simple way to build one gigantic binary linked with
everything I'll need I would be most grateful. Surely it can't be that
difficult. Ultimately, all we have are two directories of C++ source files
that need to be compiled and linked.

I've included both my scripts for building the two versions of quickfix I
have.

Many beers are available for the person who can help. :-)

Regards,
barry



*********************************************************
This is the script I used to build 1.4.0
*********************************************************
#!/bin/ksh
gcc=/opt/gnu/bin/gcc


# INCLUDE
JSEI=/opt/JDK-1.3/j2se/include
JSES=/opt/JDK-1.3/j2se/include/solaris

GCC1=/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95/2/include
GCC2=/opt/gnu/include/g++-3

QUICKFIX_I1=~
QUICKFIX_I2=~/quickfix
QUICKFIX_I3=~/quickfix/src/C++

LIBXML_I=/home/bishoba/libxml2-2.4.25/include

# LIBS
QUICKFIX_L=~/quickfix/lib


LD_LIBRARY_PATH=$LD_LIBRARY_PATH:$QUICKFIX_L

LIBS='-lsocket -lnsl -lthread -lelf'
MORELIBS='-lquickfix -lxml2'


gcc -save-temps -G -o libquickfix_jni.so -fexceptions -finline-functions
../java/*.cpp ../C++/*.cpp -lgcc -lstdc++ -lpthread -lxml2 -liberty -lz
-D_XOPEN_SOURCE=500 -lnsl -I$JSEI -I$JSES -I$GCC1 -I$GCC2 -I$QUICKFIX_I1
-I$QUICKFIX_I2 -I$QUICKFIX_I3 -I$LIBXML_I -I../../.. -I../../../include -I
/home/bishoba -L/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/ -lsocket




*********************************************************
This is the script I used to build 1.3.2
*********************************************************
#!/bin/ksh
gcc=/opt/gnu/bin/gcc


# INCLUDE
JSEI=/opt/JDK-1.3/j2se/include
JSES=/opt/JDK-1.3/j2se/include/solaris

GCC1=/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95/2/include
GCC2=/opt/gnu/include/g++-3

QUICKFIX_I1=~
QUICKFIX_I2=~/quickfix
QUICKFIX_I3=~/quickfix/src/C++

LIBXML_I=/home/bishoba/libxml2-2.4.25/include

# LIBS
LIBS='-lsocket -lnsl -lthread -lelf'
MORELIBS='-lquickfix -lxml2'


gcc -G -o libquickfix_jni.so -fexceptions -finline-functions ../C++/*.cpp
../java/*.cpp -lgcc -lstdc++ -lpthread -lxml2 -liberty -lz
-D_XOPEN_SOURCE=500 -lnsl -I$JSEI -I$JSES -I$GCC1 -I$GCC2 -I$QUICKFIX_I1
-I$QUICKFIX_I2 -I$QUICKFIX_I3 -I$LIBXML_I -I../../.. -I../../../include -I
/home/bishoba -L/opt/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.2/ -lsocket



-------------------------------------------------------
This SF.net email is sponsored by: ValueWeb: 
Dedicated Hosting for just $79/mo with 500 GB of bandwidth! 
No other company gives more support or power for your dedicated server
http://click.atdmt.com/AFF/go/sdnxxaff00300020aff/direct/01/
_______________________________________________
Quickfix-developers mailing list
Qui...@li...
https://lists.sourceforge.net/lists/listinfo/quickfix-developers


---------------------------------
Do you Yahoo!?
Yahoo! Platinum - Watch CBS' NCAA March Madness, live on your desktop!

[Quickfix-developers] Droping messages...

[Nicholas P. <nic...@sl...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hey All,

I am having some trouble with a QuickFIX application I am developing. 
Unfortunately it requires that I interface with a vendor who uses a 
bastardized version of FIX.

I have created a special XML file for validation of these messages, and 
two out of the three I have to handle get received and cracked properly. 
The third doesn't seem to get into the application at all. I have 
overridden both fromAdmin and fromApp and put logging statements in both.

For the other messages I see the log message in fromAdmin, and then 
fromApp, however for this message I see the log of the message being 
received that looks like:

<20030401-00:11:05, FIX.4.2:US->THEM, incoming>
(field=data*field=data*etc...)

but neither the fromAdmin or fromApp methods get called, and no other 
message is logged (such as rejecting due to missing or invalid fields 
which I have seen when I had the XML messed up, so I don't think that is 
the problem, but I guess it is possible. I have been over the XML with a 
fine toothed comb though so I doubt it.)

The application then goes into an  infinite loop where QuickFIX claims 
that the next message had a sequence number that was too high and re 
requests the message that it just dropped, which it drops again. Lather 
rinse repeat until the processor explodes.

The message that I receive contains fields out of order, and fields 
which print with fieldnum=NOREF, so I suspect it is a problem handling 
the crappy message from the other vendor, but since QuickFIX receives it 
they claim that it is my problem to fix. I have set:

ValidateFieldsOutOfOrder=N
ValidateFieldsHaveValues=N

in the config file with no change in behavior.

Any thoughts on a cure for this problem.

Thanks,
- -Nick

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE+iN3hR42/Somtp0QRArTAAJwLsxraN8FpGlAnH3AJsJP/wl9UoQCggqIV
IzUOnThR+n1roiPuSAgmBvE=
=fJKZ
-----END PGP SIGNATURE-----

Re: [Quickfix-developers] Build problems on Solaris

[Joerg T. <Joe...@ma...>]

Hi Barry,

> [...]

> The production machine is a very fast dual processor sun box and the
> application failed on the initial download of SecurityStatus messages which
> proceeds very quickly until the crash.
> 
> Is there a known problem using quickfix on a multi-processor machine?

You can check this easily using the Solaris pbind command. First, check the number
of processors using psrinfo:

	$ psrinfo
	0       on-line   since 10/31/02 15:54:39
	...

And then you can specify

	$ pbind -b 0 <pids>

Since bindings are inherited to all created LWPs and processes, using

	$ pbind -b 0 $$

you bind the current shell and all processes started by that shell.

Of course, this is only a fast check (and hopefully workaround), but does not solve
the problem. Oren already gave you some hints to solve your problem.

Good luck!

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