Hi there,
I am new to that group, but like the approch of how this fix-library is
generated. Thats why
I started to create the shared library today. Well, I have now a working
shared library under
linux <quickfix.so> and can start tha java-application
"Banzai".java - no problems with the shared library but, as soon as I
want to access a native method I get "java.lang.UnsatisfiedLinkError"
which occures because the c++-sources in the
directory src/java is not compiled and linked to the library generated
in src/C++.
Thats fine so lets try to compile the directory src/java with all the
generated classes from javah ...
I created a Makefile since the existing once are ignored but
URGS - this is no "ansi-C" standard but seems to be BorlandC++ code.
There are includefiles
that are NOT available under unix and all conversion-methods as well as
operators are
not compatible to g++. Even the build.xml file with ant is only
available for windows because
it uses several windows executeables ...
Now I am realy frustrated - after hours of work with the shared library
- no satisfaction in the end - sometimes I don't like computers ;-)
But perhaps sombody out there can help to solve these final problems
now. Here is what must
be done to get a shared library that resolves all symbols and manages
exeptiopns:
(1) first of all you have to compile with the option -fPIC (this makes
address-independent code which is necessary for shared libraries)
==> to do that change the line in configure.in from
< CFLAGS="-D_XOPEN_SOURCE=500 $XML_CFLAGS"
to
> CFLAGS="-D_XOPEN_SOURCE=500 -fPIC $XML_CFLAGS"
(2) change the line in src/C++/Makefile.in from
< libquickfix_la_LDFLAGS = -static
to
> libquickfix_la_LDFLAGS = -shared
(3) call ./bootstrap
./configure --enable-shared
(4) this will generate a shared library but because exceptions are used
there are still some
symbols not linked to the library :-(
If you look at the output of the link commands you will see, a line like
gcc -shared Session.lo SessionFactory.lo Parser.lo Settings.lo
ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo
SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo
SocketInitiator.lo SocketMonitor.lo SocketConnection.lo
ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo
ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo
SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib
/usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0
-o .libs/libquickfix.so.0.0.0
the problem is, that gcc is using the c-link library and NOT c++
link-library - thus exceptions
are NOT handled correctly in libraries. To achieve a working library you
must copy the complete
line and replace gcc with g++ in the directory src/C++ >> that's it !!!
g++ -shared Session.lo SessionFactory.lo Parser.lo Settings.lo
ConfigLexer.lo MessageStore.lo SocketServer.lo SocketConnector.lo
SocketStream.lo Acceptor.lo Initiator.lo SocketAcceptor.lo
SocketInitiator.lo SocketMonitor.lo SocketConnection.lo
ThreadedSocketAcceptor.lo ThreadedSocketInitiator.lo
ThreadedSocketConnection.lo FileStore.lo Dictionary.lo DataDictionary.lo
SessionSettings.lo MessageSorters.lo Utility.lo -L/usr/lib
/usr/lib/libxml2.so -lz -lm -liberty -Wl,-soname -Wl,libquickfix.so.0
-o .libs/libquickfix.so.0.0.0
===> yeahhhh - we have a shared library
(5) unfortunatelly java doesn't know anything about our new library -
thus insert in your main class
public class myMain {
static {
System.loadLibrary("quickfix");
}
static public Main(String args[]) {
... blabla ...
}
}
and don't forget to start java with the option -Djava.library.path
e.g. java -Djava.library.path=/usr/local/lib myTest
That's all.
I hope I could help to get towards a java-library under linux - I really
need that, but
currently there seems to be no chance instead of developing the complete
access-layer
in the directory src/java completly new - that sounds ugly !
with best regards
P.S. by the way - great job thoughtworks.COM - will there be a fix for
the java-code ? soon ???
|
