On Mon, 2010-01-11 at 20:06 +0100, Patrick Ohly wrote:
Congwu, can you review the "pohly" branch? I have more
which I will add there tomorrow, so you might wait a bit.
I've pushed everything that I consider ready.
On the "android" branch there are two more intrusive patches which we
should merge just yet:
Synthesis plugin: static linking without --export-dynamic
The previous solution with lookup of "SyncEvolution_<sym>" via
dlsym(RTLD_DEFAULT) in libsynthesis was non-portable. It depends on
the visibility of these functions and thus --export-dynamic.
The --export-dynamic flag is GNU ld specific. It doesn't work
on Mac OS X (unknown option) and on Android (accepted, but had no
This patch solves this by specifying the plugin functions directly
via the //static/<sym>=<addr>/... syntax. This only works with
a libsynthesis that supports that.
The advantage even on systems which support --export-dynamic is
the smaller function table and thus faster loading of the executable.
The disadvantage is the requirement to add new plugin functions
to the internal list of functions.
I pushed the corresponding libsynthesis change into our "master" branch
and now wait for Synthesis to review it. If they agree, we might change
SyncEvolution - would that be useful? I'm fairly sure it helps on Mac OS
allow compilation without exception support
On Android, exceptions are not supported.
This patch makes try/throw/catch optional by hidding them behind
macros. When compiling without exception support, throwing an
exception logs the problem and aborts the program. try/catch are
replaced with code which preserves the original program structure,
without ever executing the catch blocks.
boost/throw_exception.hpp is used to detect exception
support. boost::throw_exception() is provided as expected by Boost
when lacking exceptions.
It would be nice to turn the macros into regular error handling
code, but that is more complex and would require adding explicit
status checks after every single function call.
Right now, the code does not become larger because of the patches, just
a bit non-standard (our own macros instead of try/catch/throw). But
without adding error checks around every single function call, we can't
achieve the same level of error handling that we currently have with
proper exceptions. I have my doubts whether that is worth the effort.
Best Regards, Patrick Ohly
The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.