[Kde-pim] kdepim unbuildable with kdesrc-build

[Daniel Vrátil]

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 :-)

Dan

> 
> Regards

-- 
Daniel Vrátil
Email: dvratil at kde.org
Jabber: dan.vratil at kdetalk.net
IRC: dvratil on Freenode (#kde, #kontact, #akonadi)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20150824/90292c72/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/