Currently on my system /usr/lib64/libcdk.so.0.4.1 and symlinks are preserved by portage for net-im/licq-1.3.9. emerge @preserved-rebuild won't help, as licq will always link against the same files. It appears that dev-libs/cdk-5.0.20110517[unicode] now only creates a library called /usr/lib64/libcdkw.so.0.0.0. The canonical way to find the right library to use appears to be a call to the cdk5-config binary. The configure script for the console plugin, otoh, uses AC_CHECK_LIB to look for libcdk. I'm not sure how best to fix this issue. Addressing bug #364557 would turn this bug here from an emerge loop to a build time failure.
Created attachment 277317 [details, diff] Modification to configure This patch should theoretically address things in configure. I cannot get it to work, though: if I run eautoreconf in $S/plugins/console, then the build will fail with the following error message: ../libtool: line 481: CDPATH: command not found libtool: Version mismatch error. This is libtool 2.4, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.4 libtool: and run autoconf again. Not sure how to address this. If anyone manages that, a patch to the ebuild would probably help. Of course a commit to the portage tree would be just as fine.
Try running eutoreconf on the base directory instead with that patch.
And I meant eautoreconf, of course. :)
(In reply to comment #2) > Try running e[a]utoreconf on the base directory instead with that patch. No luck, it fails to build as the configure script in the subdir isn't recreated. checking for initCDKScreen in -lcdk... no configure: error: I can't find the cdk library. This is needed if you want to compile this plugin. Sorry. Try to get it from here: http://freshmeat.net/projects/libcdk/ As you can see, I've had licq unmerged in the mean time, so the old libcdk is no longer preserved, and I get build errors instead.
would it help if cdk5 had a configure option to set the library name, e.g., changing cdk5w to cdk5 ?
I guess it might help. I've never understood why curses was installing two libs; imho there is no reason at all to ever use libcurses when you might just as well use ncursesw. Passing that distinction through even more libs doesn't seem a particularly good idea to me.
*** Bug 374917 has been marked as a duplicate of this bug. ***
confirmed here.
Created attachment 282391 [details, diff] More modifications to configure OK, I finally got licq to compile, using this patch and the following ugly src_prepare function: src_prepare() { if use ncurses; then # preserve AM_PATH_LIBXOSD awk '/Oron Peled/,/nls.m4/' plugins/osd/aclocal.m4 | head -n-1 \ >> plugins/osd/acinclude.m4.in epatch "${FILESDIR}"/gentoo371941a.patch cat acinclude.m4.in admin/acinclude.m4.in > acinclude.m4 eautoreconf local dir for dir in "${S}"/plugins/*/configure.ac; do pushd "${dir%/*}" >/dev/null || die cat acinclude.m4.in admin/acinclude.m4.in > acinclude.m4 eautoreconf popd >/dev/null || die done fi } When configuring only some of the plugin dirs, libtool will complain about a mismatch in the version number of the LT_INIT macro, or something like this. The previous problem with CDPATH mentioned in comment #1 was due to the fact that libtoolize installed a version of ltmain.sh which relied on the definition of $lt_unset. To make this work, the LT_INIT macro from /usr/share/aclocal/libtool.m4 is needed. The configure.ac contains a call to AC_PROG_LIBTOOL which usually is an alias for it. Unfortunately the acinclude.m4 file contained a different expansion of that macro, which takes precedence over the one from /usr/share/aclocal. That's the reason I overwrote those acinclude.m4 files in all the directories. Hope that was the right thing to do. The osd plugin uses a macro called AM_PATH_LIBXOSD which was only present in the aclocal.m4 file. Thus the awk script to add it to acinclude.m4.in. After finally getting the 1.3.9 sources to compile in this fashion, I found that the latest version, 1.5.1, uses cmake instead of autotools. So as an alternative to addressing this bug here, you might want to bump the licq version as requested in bug #339673.
Created attachment 282403 [details, diff] cmake fix for licq 1.5.1 licq-1.5.1 using the ebuild from bug #339673 comment #5 is affected by this issue here as well. This patch takes care of things.
This should be fixed with licq-1.6.0
*** Bug 403465 has been marked as a duplicate of this bug. ***
*** Bug 411287 has been marked as a duplicate of this bug. ***
I'd assume this is fixed by the recent bump to 1.7.0 (thank you Lars!) in https://bugs.gentoo.org/show_bug.cgi?id=339673
Indeed this is fixed.
