[Kde-pim] kdepim unbuildable with kdesrc-build

Mon Aug 24 18:53:53 BST 2015

On Monday 24 August 2015 19:03:18 Daniel Vrátil wrote:
> On Monday, August 24, 2015 6:54:07 PM CEST you wrote:
> > Le lundi 24 août 2015, 18:47:30 CEST Daniel Vrátil a écrit :
> > > On Monday, August 24, 2015 12:04:04 PM CEST Milian Wolff wrote:
> > > > On Monday, August 24, 2015 11:42:10 AM CEST Volker Krause wrote:
> > > > > Hi Martin,
> > > > > 
> > > > > sorry about that.
> > > > > 
> > > > > I'm not exactly sure what is wrong here, I use kdesrc-build myself,
> > > > > for
> > > > > kdepim and everything else of KDE I use, and never had this issue
> > > > > with
> > > > > kdepim. Last time I saw similar issues was in the very early KF5
> > > > > days,
> > > > > when
> > > > > stuff was still moving a lot, and you are right, these issues are
> > > > > very
> > > > > frustrating to debug.
> > > > > 
> > > > > I also usually have the old builds still around, both in build and
> > > > > install
> > > > > locations, so that sounds similar to your setup, and my kdesrc-build
> > > > > configuration is pretty much vanilla upstream.
> > > > > 
> > > > > I'm also not aware of anything non-standard we do regarding library
> > > > > search
> > > > > paths etc, so without further input I unfortunately have no idea how
> > > > > to
> > > > > improve the situation :-(
> > > > > 
> > > > > Anyone else seeing this, or similar issues with building manually?
> > > > > Which
> > > > > library is picked up over which other one in the case things go
> > > > > wrong,
> > > > > for
> > > > > which target, and what do the CMake config files say for those
> > > > > libraries?
> > > > > I
> > > > > have seen switching between debug and release builds creating
> > > > > duplicate
> > > > > config files, and thus resulting in an outdated one still being
> > > > > around
> > > > > after some time, something similar might be happening here.
> > > > 
> > > > Personally, I saw it just yesterday. It happened in kdepim (the git
> > > > repo,
> > > > not the meta module), with nearly all libs, sadly I forgot the exact
> > > > reason
> > > > - it was complaining about missing unresolved symbols - I forgot which
> > > > ones. A make uninstall && make install fixed it for me.
> > > 
> > > I think the reason could be that some of the shared libraries (like
> > > libkmailprivate.so) have all their dependencies linked privately, even
> > > though some of the dependencies are used in their headers. Other
> > > binaries
> > > that link against them then get linked against the wrong libs, probably
> > > because of some cmake-target-linking-interface-visibility-black-magic
> > > thing.
> > > 
> > > As an example, I just got linking error of kmail_part.so due to
> > > undefined
> > > KMime symbols in /opt/kde-devel/lib64/libmessageviewer.so. kmail_part.so
> > > does not link against it directly, but it links against
> > > libkmailprivate.so,
> > > which has links messageviewer links against messageviewer (privately).
> > > Moving messageviewer to public linking interface of kmailprivate fixed
> > > the
> > > build subsequently for me.
> > > 
> > > Here is the full patch I used to make my kdepim compile today:
> > > https://paste.kde.org/pobglzrie
> > > 
> > > I'm not sure if this is really the case, but if really is, then this
> > > patch
> > > only fixes the today case and we need some better method how to detect
> > > that
> > > we are missing dependencies in public linking interface...
> > > 
> > > Dan
> > 
> > Hi,
> > For me CI doesn't show linking error so it's build from existing lib on
> > system.
> > I am not sure that add this patch is really useful as by default it links
> > correctly in CI (and I build all from scratch today without error).
> 
> I'm not saying to add it, I'm not even sure if it's the proper fix (and if
> it is it's incomplete). Just wanted to show what might be going on.
> 
> > If there is a missing dependancy CI will inform us no ?
> > 
> > On a clean system it compiles fine.
> 
> Yes, the problem only happens when you already have kdepim installed in your
> system (say /opt/kde-devel/) and you try to build kdepim again (clean or
> non- clean). Some targets will then try to link against kdepim libraries
> installed in /opt/kde-devel/lib64 first, falling back to
> ${CMAKE_BINARY_DIR} if they don't exist there.  This will be OK most of the
> time but fails when the installed libraries have unresolved symbols. Like
> today it failed for me because KMime ABI changed over the weekend, so I
> built and installed KMime, then tried to build kdepim and it failed because
> even though $
> {CMAKE_BINARY_DIR}/messageviewer/libmessageviewer.so was linked correctly
> against the new KMime ABI, /opt/kde-devel/lib64/libmessageviewer.so was not
> and kdepim tried to link against the installed (broken) one instead of the
> freshly built one.
> 
> That's the reason why it does not fail in CI - kdepim is not installed there
> as a dependency for its own builds, so the build system always find the
> freshly-built libraries in ${CMAKE_BINARY_DIR} and everything is fine.
> 
> I don't know why it fails for some people, could be caused by different
> options we pass to cmake when running it, could be some environment
> variable, could be linker even...who knows :-)

That confirms my earlier theory I think, the problem is that indirect 
dependencies are picked up from the install location, rather than the build 
dir. This is worked around by having direct dependencies (moving things to 
PUBLIC), for those CMake gives us absolute paths and thus no problem.

Looking at the link line posted by Christophe, there is actually no search 
path in there at all, so the only way the linker could possibly find indirect 
dependencies is via rpath? I think we need to understand that part to find a 
proper fix.

One workaround I can think of is change the library output dir to $build/lib 
for example (to have all in one place), and add that to the linker search 
path. But that feels like patching up the symptoms of another problem at this 
point.

In any case, I don't think adding all indirect dependencies to the public link 
interface is the right way. Stripping out all unused dependencies and ordering 
the rest by hit probability cuts KMail dynamic linking time down by 30-45%, 
ie. this actually matters.

regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 173 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150824/ab78fd84/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/