Re: [SyncEvolution] git update + testing

On Mon, 2010-01-11 at 20:06 +0100, Patrick Ohly wrote: 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 effect). 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 X. 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.