Libraries which depend on libgnomecanvasmm, like libgnomeuimm, doesn't work anyone. The problems is related to the /usr/lib/libgnomecanvasmm-2.6.la file. The original library_names suggest that libgnomecanvasmm-2.6 is valid, but it's not because it's a directory. This will cause libraries using -llibgnomecanvasmm-2.6 to fail with some like can't open /usr/lib/libgnomecanvasmm-2.6. The problem seems to be that normally libraries have the .so at the end, but for some unkown reason to me, this ebuilds installs them without... The real fix would be to reverse this stripping of the .so of the libraries installed. This simple patch fixes it for now, add the following to the end of the ebuild: pkg_postinst() { #Fix broken .la cd /usr/lib/ sed -e "s:library_names='libgnomecanvasmm-2.6.1.0.1 libgnomecanvasmm-2.6 .1 libgnomecanvasmm-2.6':library_names='libgnomecanvasmm-2.6.1.0.1 libgnomecanva smm-2.6.1':g" \ libgnomecanvasmm-2.6.la > libgnomecanvasmm-2.6.la.hacked mv libgnomecanvasmm-2.6.la.hacked libgnomecanvasmm-2.6.la }
could you provide your "emerge info" please. Also, are you telling me that you do not have these files in /usr/lib ? : libgnomecanvasmm-2.6.so libgnomecanvasmm-2.6.so.1
I forgot to mention, what I meant by the previous statement is that are those symlinks valid?
emerge info: Portage 2.0.50-r7 (default-x86-1.4, gcc-3.4.0, glibc-2.3.3_pre20040420-r1, 2.6 -mm5) ================================================================= System uname: 2.6.6-mm5 i686 AMD Athlon(tm) XP 2100+ Gentoo Base System version 1.4.15 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O3 -march=athlon-xp -pipe" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3 hare/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/ ipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/conf / /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/contro CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O3 -march=athlon-xp -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="http://ftp.easynet.nl/mirror/gentoo/ ftp://sunsite.informatik. th-aachen.de/pub/Linux/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/home/arj/overlay" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X alsa apm avi berkdb crypt encode esd foomaticdb gdbm gif gtk gtk2 imlib pv6 jpeg libg++ libwww mad mikmod motif mozilla moznocompose moznoirc moznomai mozsvg mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python q cktime readline sdl slang spell ssl tcpd tetex truetype x86 xft xml2 xmms xv z b"
Yes: ls -l /usr/lib/libgnomecanvasmm* lrwxrwxrwx 1 root root 26 May 28 03:04 /usr/lib/libgnomecanvasmm-2.6.1 -> libgnomecanvasmm-2.6.1.0.1 -rwxr-xr-x 1 root root 263556 May 28 03:04 /usr/lib/libgnomecanvasmm-2.6.1.0.1 -rw-r--r-- 1 root root 1432 May 28 03:04 /usr/lib/libgnomecanvasmm-2.6.la /usr/lib/libgnomecanvasmm-2.6: total 8 drwxr-xr-x 2 root root 4096 May 28 01:27 include drwxr-xr-x 3 root root 4096 May 28 01:27 proc
Let me ask you something, have you been using third party ebuilds? We only have libgnomecanvasmm-2.6.0 in the tree, so I am confused how you are getting the 2.6.1 version.
No, I simply bumped the ebuild to have it compile on gcc-3.4.
I can't support what users do to their own systems.
The latest in portage is also just a bump of the 2.6.0 ebuild. Anyway... emerge sync emerge unmerge libgnomecanvasmm emerge libgnomecanvasmm And surely enough the problem still persists with the ebuild from the official portage tree.
If you updated to have it compile against gcc-3.4, how can you revert back to the old version without it breaking? Anyhow, if you feel that this is a gentoo problem, attach your emerge log.
Created attachment 32287 [details] emerge log Now I understand why you closed the bug. 2.6.1 builds with gcc-3.4 while 2.6.0 didn't. That is why I said I bumped it. And now 2.6.1 is in portage but it's still broken on my machine. I've attached an emerge log.
the libtool archive contains library_names='libgnomecanvasmm-2.6.1.0.1 libgnomecanvasmm-2.6.1 libgnomecanvasmm-2.6'. this should be library_names='libgnomecanvasmm-2.6.1.0.1 libgnomecanvasmm-2.6.1' if you dont want things to break, since libgnomecanvasmm-2.6 is a directory (i know... oddity). perhaps some sed magic is needed here?
Anders, I'd like to apologize, I did not know that libgnomecanvasmm has been updated. We are working on a solution right now, but if it is urgent for you, comment out these lines: aclocal -I scripts automake -c -f autoconf in the ebuild under the src_compile() function, that should solve your problem.
i should really read the bug before i post. and nevermind, seems there was an easier fix: remove a previous amd64 fix that's no longer needed. thanks for the heads up khai
No problem Khai, glad you found the problem. I wondered why it had to run the autotools before building but didn't look into it further.
it simply was wrong of lv here to bump it without notifying anyone of the gnome team, no need to apologize for that.
My fault ! Sorry ;-) Adding "if [ ${ARCH} = amd64 ]; ..." to all the ebuilds I changed.
Danny's fix in cvs solves this.
