After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 689301 - build fails with cannot find -lQtCore in Gentoo
build fails with cannot find -lQtCore in Gentoo
Status: RESOLVED WONTFIX
Product: ekiga
Classification: Applications
Component: Build System
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: Ekiga maintainers
Ekiga maintainers
Depends on:
Blocks:
 
 
Reported: 2012-11-29 18:41 UTC by Daniel Santos
Modified: 2012-11-30 08:11 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4


Description Daniel Santos 2012-11-29 18:41:51 UTC 
I'm not yet 100% certain it isn't due to distro patches, but I did a cursory review and didn't see any changes that would cause it.

Downstream bug: https://bugs.gentoo.org/show_bug.cgi?id=442628
Related bug: https://bugzilla.gnome.org/show_bug.cgi?id=577878

Full build logs can be found on the Gentoo bug report.  Essentially, KAB_LIBS is being set to "-lQtCore -lkabc" and we need to add -L<qt library path>, which in my case happens to be "-L/usr/lib64/qt".  This is properly sniffed out and added to KDE_LIBS, but not KAB_LIBS.

Might I suggest adding an entirely new variable called QT_LIBS (or some such) to encapsulate this functionality of finding the qt lib path and then just expand that into both KAB_LIBS and KDE_LIBS?  Perhaps even put the "-lQtCore" in it (not sure on that part).

I'm no expert in autotools or I would propose a patch for you.
Comment 1 Snark 2012-11-29 19:45:06 UTC 
Well, this piece of code is explicitly marked as experimental, so it's a distribution bug to enable it by default.

I'll gladly apply correcting patches if given, but as far as I know no ekiga developer will work on it spontaneously.
Comment 2 Daniel Santos 2012-11-30 01:18:35 UTC 
Thanks so much for the response! This is enabled when the USE="kde" flag is enabled.  This flag has a global description, but also "local" descriptions, specific to certain packages.  I'll made sure a local description is added to this package (net-voip/ekiga in Gentoo) describing it as experimental.  Somebody said that they will fix it this weekend, so I'll make sure the patch makes its way to you guys (if he forgets to send it upstream)

Thanks again!
Comment 3 Snark 2012-11-30 08:11:46 UTC 
Yes, it would be good if it were documented as experimental.

Notice that this code hasn't been run since long, so fixing the compilation might still give something which doesn't work quite correctly, though I'd gladly be told otherwise.