El día Thursday, May 05, 2011 a las 05:16:11PM +0100, David Woodhouse escribió:
> 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 ?
Correct, I have cut&paste the wrong name from my debugging log file;
> So your *calendar* works, but presumably not
> your address book?
Correct, the GAL stoped working; but I could managed this to work again
when after accessing the calendar, making libebookbackendexchange.so
visible again before using GAL for the first time in Evo;
> 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.
Yes, I saw this whith truss(1) also that after mmap(2) of all shared
libs the libebook*.so get unmap(2)'ed again;
>
> 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.
I have checked the man pages of dlopen(3); there is no definition what
will happen with bound symbols on dlclose(3); I could bring this up in
the FreeBSD-hackers list, but I think it should be fixed by a better
design in Evolution itself (as you said about 3.x);
> 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.
Should I wait for some kind of fix for 2.32.x? Meanwhile I will compile
all again with clean sources from 2.32.3 (to remove all my debugging
inserts) and will try to find some dirty
workaround, for example with file permissions and setuid-bit so that
e-calendary-factory can not open the libebookbackendexchange.so while
the e-addrbook-factory can do it...
At least we do know now what the problem is in detail; this is good
news, I think;
thanks for all your hints and help on the way through.
matthias
--
Matthias Apitz
t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
e <g...@unixarea.de> - w http://www.unixarea.de/
_______________________________________________
evolution-list mailing list
evolution-list@gnome.org
To change your list options or unsubscribe, visit ...
http://mail.gnome.org/mailman/listinfo/evolution-list
