Re: [Evolution] evolution-2.32.1 (FreeBSD HEAD) && calendar not working

[David Woodhouse <dwmw2 infradead org>]

On Thu, 2011-05-05 at 13:30 +0200, Matthias Apitz wrote:
> as you can see e2k_ascii_strcase_hash() is in two shared libs and with
> the same last bits of the correct addr and the broken addr; as I wild
> guess I simply renamed 'libecalbackendexchange.so' to get it out of the
> way; the e-calendar-factory complains about it: 
> (e-calendar-factory:36266): e-data-server-WARNING **: Cannot open
> "/usr/local/lib/evolution-data-server-1.2/extensions/libebookbackendexchange.so"

I think you renamed libebookbackendexchange.so, not
libecalbackendexchange.so ? So your *calendar* works, but presumably not
your address book?



I see the problem now.

We build these 'library' functions in the server/lib/ directory into a
static library 'libexchange.a', and that whole thing gets included into
*both* the calendar and the addressbook plugins. So of course the same
function exists in *both* of the shared libraries that get loaded.

The addressbook plugin then gets *unloaded*, I think, when the
calendar-server decides that it isn't a calendar plugin.

And I think that what you're seeing here is a bug in your platform's
dynamic linker. Even though the addressbook plugin got unloaded, the
internal symbols in the calendar plugin get resolved to point at it.

Then again, maybe it's not a bug; maybe it's just undefined behaviour. I
don't remember what is *expected* to happen in this case.

But quite frankly, we got what we deserve; we *know* that weird shit
happens on a lot of platforms when we do that, so we shouldn't have been
doing it in the first place. We should have made our 'libexchange' into
a shared library, or played namespace/linker-script tricks to ensure
that those functions weren't *exported* from our plugin 'library'
objects.

I think you'll find this is 'fixed' in Evolution 3.0 merely because the
calendar factory no longer loads the addressbook plugins, and vice
versa; they are stored in separate directories now.

But I suspect we should still fix it *properly* anyway.

-- 
dwmw2