Re: late binding during exception handling
- From: Larry Smith <lsmith@xxxxxxxxxx>
- Date: Sat, 28 Oct 2006 21:37:29 GMT
ben mitch wrote:
hi
we are currently porting an application to linux and are having a
problem. i'm no expert on linkage etc., least of all under linux, but it
appears to be a symbol-resolution problem, possibly related to lazy/late
binding of symbols in a shared library. the layout is
manager (executable)
core.so
process.so
and the problem arises as follows:
* start manager
* manager calls function exported from process.so to create an object X
* manager spawns a new worker thread (posix)
* worker thread calls member function of X
* member function of X throws a custom exception E, defined in core.so
* exception propagates back up to manager (in worker thread)
* exception type is unrecognised (i.e. is caught by catch(...))
currently, we catch the unknown exception, wrap it up in a nice
exception, and this eventually returns us to prompt, with information
lost since we never saw the actual exception thrown by process.
interestingly, if we call the manager to do the same thing again without
rebuilding (and again and again), on all subsequent calls the manager
recognises the thrown exception correctly, which is what makes me think
that binding is not getting done in time.
i thought (hope this doesn't sound too naive) that maybe during
exception handling it was already too late to bind to the exception
symbols in core, and hence the first exception thrown has to be handled
before it is bound. just a wild guess, perhaps someone has something
better!
all is written in C++, compiled using gcc (details below). compiler
switches are as follows:
core:
-pthread -O3 -ffast-math -Werror -fPIC -shared --export-dynamic
manager statically-linked component modules:
-pthread -O3 -ffast-math -Werror -fPIC
manager executable build:
-fPIC -ansi -D_GNU_SOURCE -pthread -O3 -ffast-math -DNDEBUG -pthread
-shared -m32 --export-dynamic
process:
-pthread -O3 -ffast-math -Werror -fPIC -shared
platform info:
MACHTYPE=i586-mandrake-linux-gnu
-bash-2.05b$ uname -a
Linux xxx.xxx.xxx.xxx 2.4.22-10mdk #1 Thu Sep 18 12:30:58 CEST 2003 i686
unknown unknown GNU/Linux
-bash-2.05b$ gcc --version
gcc (GCC) 3.3.1 (Mandrake Linux 9.2 3.3.1-2mdk)
sorry if i left anything out, let me know. and thanks in advance for any
help you can offer.
cheers
ben
For correct operation, C++ must be Compiled and Linked
with 'g++', not 'gcc', eg:
// compile 'manager' source files
g++ -c a.cpp
g++ -c b.cpp
...
// compile 'core' source files
g++ -c -fPIC -pthread d.cpp
g++ -c -fPIC =pthread e.cpp
...
// compile 'process' source files
g++ -c -fPIC -pthread f.cpp
g++ -c -fPIC =pthread g.cpp
...
// link 'core' shared lib (does not depend on 'process')
g++ -ocore.so -fPIC -pthread d.o e.o
// link 'process' shared lib (depends on 'core')
g++ -oprocess.so -fPIC -pthread f.o g.o -lcore
// link source into executable 'manager', being
// sure to specify the req'd libs in the correct
// order
g++ -o manager a.o b.o -lprocess -lcore
Since the are no Windows style IMPLIB's in Linux,
the 'core' and 'process' shared libs can NOT depend on
each other at compile/link time (ie. if 'process' calls
functions in 'core', then 'core' can NOT call functions
in 'process' - that would be a problematic 'circular
reference').
You'll get additional help on the correct compile/link
switches in the g++ newsgroup:
gnu.g++.help
.
- Follow-Ups:
- Re: late binding during exception handling
- From: Paul Pluzhnikov
- Re: late binding during exception handling
- References:
- late binding during exception handling
- From: ben mitch
- late binding during exception handling
- Prev by Date: Re: Automatically controlling the mouse and keyboard for GUI scripting?
- Next by Date: Re: late binding during exception handling
- Previous by thread: late binding during exception handling
- Next by thread: Re: late binding during exception handling
- Index(es):
Relevant Pages
|
|
