GNOME Bugzilla – Bug 781485
Fails to build tests after update to evolution-data-server 3.24.1
Last modified: 2017-07-02 21:52:33 UTC
Created attachment 350048 [details] Build log After updating to evolution-data-server 3.24.1, folks 0.11.3 fails to build. The same problem is exhibited with folks git master. It appears that folks is trying to link or use symbols from a private library in e-d-s: /usr/bin/ld: warning: libedbus-private.so, needed by .libs/libfolks-eds.so.1.2, not found (try using -rpath or -rpath-link) /usr/X11R6/lib/libGL.so.17.1: warning: warning: random() may return deterministic values, is that what you want? .libs/libebackend-1.2.so.6.0: undefined reference to `e_dbus_source_remote_deletable_complete_delete' .libs/libebackend-1.2.so.6.0: undefined reference to `e_dbus_object_get_source' .libs/libebook-1.2.so.20.0: undefined reference to `e_dbus_address_book_cursor_get_total' .libs/libedataserver-1.2.so.20.1: undefined reference to `e_dbus_source_oauth2_support_call_get_access_token_sync' .libs/libedata-book-1.2.so.17.0: undefined reference to `e_dbus_address_book_set_locale' .libs/libebook-1.2.so.20.0: undefined reference to `e_dbus_direct_book_proxy_new_sync' [etc] When I run ldd manually against one of these libraries (note that the .libs/ are symlinks into /usr/local/lib/...) I see the following: 000016c213379000 000016c2135cf000 rlib 0 5 0 /usr/local/lib/evolution-data-server/libedbus-private.so Eventhough there is an RPATH annotation with the right locations: RPATH /usr/local/lib:/usr/local/lib/evolution-data-server It does not appear to be picked up. Now this e-d-s release is built with cmake and does not install any .la files. If I take the .la files from the 3.22.x release of e-d-s and adjust it for 3.24.x then folks correctly builds. Other projects using e-d-s do not suffer from this problem, e.g. glabels, evolution, gnome-maps, etc). Any help in pinpointing the source of this problem would be greatly appreciated. Whether it's vala, the linker/libtool or something else that's causing this issue. Full build log is attached.
Builds fine for me. Nothing in how libfolks links to EDS has changed in quite some time, so I suspect this is a bug in EDS introduced in its port from autotools to cmake. Possibly a private library dependency leaking into an installed .pc file?
Thanks for a bug report. None eds .pc file contains libedbus-private, thus it's not it. I made a clean checkout of libfolks from git and its master branch builds fine here (when configured with --prefix=xxx --disable-fatal-warnings --enable-vala). Fedora builds against 3.24.1 just fine, as can be seen here: https://koji.fedoraproject.org/koji/taskinfo?taskID=19081150 I suspect some stale file in the build folder of folks on Jasper's side. Please try `make distclean` or `git clean -xfd` and then build again.
Hi Milan. I can reproduce it on an empty system. $ objdump -x /usr/local/lib/libedataserver-1.2.so.20.1 |grep NEEDED.*private.* NEEDED libedbus-private.so Now, folks links to libedataserver-1.2.so but for some reason fails to find libedbus-private.so (needed by that lib) which is installed under /usr/local/lib/evolution-data-server/ (a non standard lib directory; although that should not be an issue since rpath it properly set as seen below). What I don't get is that rpath looks correctly set: $ objdump -x /usr/local/lib/libedataserver-1.2.so.20.1 |grep RPATH RPATH /usr/local/lib:/usr/local/lib/evolution-data-server What's strange is that folks is the *only* package that has that particula issue in our entire ports tree (10k+ packages). Everything else using e-d-s has no problem. I'm a bit puzzled... While that may only be obvious on OpenBSD, maybe it's a real bug? Thanks.
I have this on a fresh Fedora 25 too, with locally built eds. Could you provide your full build log, ideally with verbose make, please? I would also verify that there is no evolution-data-server-devel package installed, thus there is no problem between your local build of eds and the system eds.
(In reply to Milan Crha from comment #4) > I have this on a fresh Fedora 25 too, with locally built eds. Could you > provide your full build log, ideally with verbose make, please? I would also > verify that there is no evolution-data-server-devel package installed, thus > there is no problem between your local build of eds and the system eds. Hi Milan. You can find an e-d-s full build log at: https://www.bsdfrog.org/tmp/eds-build.txt The evolution-data-server package was not installed during that build; also note that on OpenBSD there's no concept of "-devel" packages. A typical package contains everything (bins, libs, headers...). Thanks.
I meant full build log of ffgtk, not eds. Verbose make means sometimes `make V=1`, sometimes `make VERBOSE=1`, it depends on the build system (first usually for autotools, second for CMake).
(In reply to Milan Crha from comment #6) > I meant full build log of ffgtk, not eds. Verbose make means sometimes `make I assume you meant folks, not "ffgtk" :-) Here it is: https://www.bsdfrog.org/tmp/folks-build.txt
I had a similar problem when I tried to build evolution 3.24.1 on Ubuntu. Debian's evolution-data-server has this patch but I don't know how to port it to 3.24: https://sources.debian.net/src/evolution-data-server/unstable/debian/patches/01-noinst-libedbus-private.patch/
*** Bug 781626 has been marked as a duplicate of this bug. ***
Antoine, I'm curious what your e-d-s build log says. Could you repost it? My problem building evolution was because I didn't have libedbus-private.so installed. It works now and building folks against e-d-s 3.24.1 works too.
(In reply to Jeremy Bicha from comment #10) > Antoine, I'm curious what your e-d-s build log says. Could you repost it? > > My problem building evolution was because I didn't have libedbus-private.so > installed. It works now and building folks against e-d-s 3.24.1 works too. Hi Jeremy. Sure, it's back at: https://www.lphp.org/tmp/eds-build.txt
Created attachment 350440 [details] [review] proposed folks patch (In reply to Antoine Jacoutot from comment #7) > I assume you meant folks, not "ffgtk" :-) Ouch, right, of course :) Your log says: > warning: library filename /usr/local/lib/evolution-data-server/libedbus-private.so has no version number when linking libfolks-eds.so.1.2 and it is also included as -ledbus-private for the linker. Similarly with eds.so. But when linking persona-store-tests, the edbus-private is not part of the command line. Could you try with this folks patch, please? Note: it changes Makefile.am, thus a re-configure is needed. I would even try ./autogen.sh, but your build log shows a claim that autoconf is missing, which is a bit weird to me, but what I know. Note2: tests/lib/eds/Makefile.am contains more CFLAGS and LIBS which may or may not be needed too. It builds fine for me, thus please try and eventually update the patch with more added pieces.
> Your log says: > > > warning: library filename /usr/local/lib/evolution-data-server/libedbus-private.so has no version number Yes, that's a warning from our libtool. It's only triggered when we link to an unversionned solib. But it has no consequences, it's just because on OpenBSD we always version library names but things still work without it. It's more of a reminder for our own stuff in the base system. So no worries here :-) > when linking libfolks-eds.so.1.2 and it is also included as -ledbus-private > for the linker. Similarly with eds.so. > > But when linking persona-store-tests, the edbus-private is not part of the > command line. > > Could you try with this folks patch, please? Just tried it and it works! > Note: it changes Makefile.am, thus a re-configure is needed. I would even > try ./autogen.sh, but your build log shows a claim that autoconf is missing, > which is a bit weird to me, but what I know. That's because autoconf is a wrapper on OpenBSD. It allows us to use multiple versions of autoconf by setting the AUTOCONF_VERSION env var accordingly. In this case, I do it at autoreconf + configure phase but not at build phase (it's not necessary to build) where you see the warning. > Note2: tests/lib/eds/Makefile.am contains more CFLAGS and LIBS which may or > may not be needed too. It builds fine for me, thus please try and eventually > update the patch with more added pieces. It looks like there's no need to add anything more, folks build fine for now now. Thanks Milan!
Ah hold on a bit. I may have spoken too fast (wrong build box).
OK sorry for that. YES it does work. Thanks again.
Review of attachment 350440 [details] [review]: Looks good to me, thanks.
Philip, could you do a new folks release so that folks is buildable with the current stable GNOME series?
(In reply to Jeremy Bicha from comment #17) > Philip, could you do a new folks release so that folks is buildable with the > current stable GNOME series? I’ll try, but given that some of the unit tests need to be fixed before I can release, I realistically won’t get a release out for a few weeks.
After several hours of fighting valac and valadoc, I’ve released 0.11.4, containing the fix for this bug.