GNOME Bugzilla – Bug 781626
e_dbus_* symbols are no longer exported in 3.24
Last modified: 2017-04-26 09:09:11 UTC
I built evolution-data-server 3.24.1 on Ubuntu 17.04 and a very large number of e_dbus_* symbols are no longer being exported. Is this intentional? If so, my understanding is that the soname should have been bumped, but the only affected library where this was done is libebook (which also had e_gdbus_* symbols go missing). The affected libraries are: libedataserver-1.2-22 libebook-1.2-19 libedata-book-1.2-25 libecal-1.2-19 libedata-cal-1.2-28 libebackend-1.2-10
I'm going to go ahead and mark this as a duplicate of bug 781485 since the symbol problem could be caused by my trying not to install libedbus-private. *** This bug has been marked as a duplicate of bug 781485 ***
(In reply to Jeremy Bicha from comment #1) > I'm going to go ahead and mark this as a duplicate of bug 781485 since the > symbol problem could be caused by my trying not to install libedbus-private. Not to install libedbus-private? Why? It is a private library and it's a dynamic library, thus instead of statically linking it into several libraries which use it it is there only once, and the libraries using it do not export the symbols from there. Thus yes, it is intentional to not export private library symbols in public libraries. Again, 'private' is the key word here, there is no public API which would let you access those symbols through those public libraries using this private library.
Hi, could you read the description from https://sources.debian.net/src/evolution-data-server/unstable/debian/patches/01-noinst-libedbus-private.patch/ ?
Yes, I can. It mentions "problem on Windows". Hmm, eds can be built there, when webkitgtk4 dependency is disabled, thus no internal Google OAuth authentication allowed. It mentions "undefined symbols in runtime". I see, that's a big issue. Is it still for Windows only? I didn't notice this issue when playing with eds in time of 3.18.x on Windows, the libedbus-private.dll is installed into $PREFIX/bin, just as any other library on Windows, thus the executables can find them. That patch mentions 3.16.x, which predates my tests. As I mentioned above, static linking can cause trouble. If you want to keep there that custom patch just because "it used to work in past", then maybe consider to retest, because it can be outdated (not needed) these days. I'm willing to help, but the things mentioned in the patch are not conformant with my previous (also rather old) testing.