Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 106773 - dev-cpp/gtkmm-2.6.4 emerge fails
Summary: dev-cpp/gtkmm-2.6.4 emerge fails
Status: RESOLVED INVALID
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Unspecified (show other bugs)
Hardware: x86 Linux
: High normal (vote)
Assignee: GNOME C++ Bindings Maintainers (OBSOLETE)
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-09-21 03:51 UTC by chris
Modified: 2006-08-13 17:51 UTC (History)
0 users

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description chris 2005-09-21 03:51:09 UTC
GTKMM will not compile.

Reproducible: Always
Steps to Reproduce:
ACCEPT_KEYWORDS="~x86"
1. emerge -Duav world
2. gtkmm is listed as one of the packages needed.

Actual Results:  
gtkmm emerge fails

Expected Results:  
Should have compiled successfully, no?

localhost chris # gcc-config -c                                                
i686-pc-linux-gnu-3.4.4
localhost chris # emerge info                                                  
Portage 2.0.52-r1 (default-linux/x86/2005.1, gcc-3.4.4, glibc-2.3.5-r1, 2.6.13-g
entoo-r2 i686)
=================================================================
System uname: 2.6.13-gentoo-r2 i686 Mobile AMD Athl
Gentoo Base System version 1.12.0_pre8
dev-lang/python:     2.3.5-r2, 2.4.1-r1
sys-apps/sandbox:    1.2.13
sys-devel/autoconf:  2.13, 2.59-r7
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6
sys-devel/binutils:  2.16.1
sys-devel/libtool:   1.5.20
virtual/os-headers:  2.6.11-r2
ACCEPT_KEYWORDS="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.4/env /usr/kde/3.4/share
/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/
mozilla/defaults/pref /usr/share/config /var/qmail/control"
CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d"
CXXFLAGS="-O2 -march=athlon-xp -pipe -fomit-frame-pointer"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig distlocks sandbox sfperms strict"
GENTOO_MIRRORS="http://distro.ibiblio.org/pub/linux/distributions/gentoo/ http:/
/gentoo.arcticnetwork.ca/"
MAKEOPTS="-j2"
PKGDIR="/usr/portage/packages"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
SYNC="rsync://rsync.us.gentoo.org/gentoo-portage"
USE="x86 X acpi alsa apm arts avi berkdb bitmap-fonts browserplugin cdb cdparano
ia cdr clamav crypt cups curl divx4linux dri dvd dvdr eds emacs emboss encode es
d fam foomaticdb fortran gd gdbm gif gnome gphoto2 gpm gstreamer gtk gtk2 ieee13
94 imagemagick imlib ipv6 java jikes jpeg ldap libg++ libwww lm_sensors mad mikm
od mmx motif mozilla mp3 mpeg ncurses nptl-only ogg oggvorbis opengl oss pam pda
 pdflib perl png python quicktime readline samba sdl sharedmem spell sse ssl sym
link tcpd threads tiff truetype truetype-fonts type1-fonts unicode usb userlocal
es v4l vorbis xine xml2 xmms xv zlib userland_GNU kernel_linux elibc_glibc"
Unset:  ASFLAGS, CTARGET, LANG, LC_ALL, LDFLAGS, LINGUAS, PORTDIR_OVERLAY
Comment 1 chris 2005-09-21 03:54:34 UTC
Here's the tail end of the emerge -Duv world:

Making all in extra_defs_gen
make[3]: Entering directory
`/var/tmp/portage/gtkmm-2.6.4/work/gtkmm-2.6.4/tools/extra_defs_gen'
if i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../.. -I../../gdk -I../../gtk
-DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/glibmm-2.4
-I/usr/lib/glibmm-2.4/include -I/usr/include/sigc++-2.0
-I/usr/lib/sigc++-2.0/include -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2
-I/usr/include/freetype2/config      -O2 -march=athlon-xp -pipe
-fomit-frame-pointer -Wall -MT generate_defs_gtk.o -MD -MP -MF
".deps/generate_defs_gtk.Tpo" -c -o generate_defs_gtk.o generate_defs_gtk.cc; \
then mv -f ".deps/generate_defs_gtk.Tpo" ".deps/generate_defs_gtk.Po"; else rm
-f ".deps/generate_defs_gtk.Tpo"; exit 1; fi
/bin/sh ../../libtool --tag=CXX --mode=link i686-pc-linux-gnu-g++  -O2
-march=athlon-xp -pipe -fomit-frame-pointer -Wall   -o generate_extra_defs 
generate_defs_gtk.o  -lglibmm-2.4 -lsigc-2.0 -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpangoft2-1.0
-lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0  
-lglibmm_generate_extra_defs-2.4
mkdir .libs
i686-pc-linux-gnu-g++ -O2 -march=athlon-xp -pipe -fomit-frame-pointer -Wall -o
generate_extra_defs generate_defs_gtk.o  /usr/lib/libglibmm-2.4.so
-L/usr/i686-pc-linux-gnu/bin -L/usr/i686-pc-linux-gnu/lib
/usr/lib/gcc/i686-pc-linux-gnu/3.4.4/libstdc++.so
-L/usr/lib/../i686-pc-linux-gnu/lib /usr/lib/libgtk-x11-2.0.so
/usr/lib/libgdk-x11-2.0.so /usr/lib/libatk-1.0.so /usr/lib/libgdk_pixbuf-2.0.so
/usr/lib/libpangoxft-1.0.so /usr/lib/libpangox-1.0.so
/usr/lib/libpangoft2-1.0.so /usr/lib/libpango-1.0.so -lm
/usr/lib/libglibmm_generate_extra_defs-2.4.so /usr/lib/libsigc-2.0.so
/usr/lib/libgobject-2.0.so /usr/lib/libgmodule-2.0.so /usr/lib/libglib-2.0.so
-ldl /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so
/usr/lib/libglibmm-2.4.so: undefined reference to
`sigc::internal::signal_impl::erase(std::_List_iterator<sigc::slot_base,
sigc::slot_base&, sigc::slot_base*>)'
/usr/lib/libglibmm-2.4.so: undefined reference to
`sigc::internal::signal_impl::insert(std::_List_iterator<sigc::slot_base,
sigc::slot_base&, sigc::slot_base*>, sigc::slot_base const&)'
collect2: ld returned 1 exit status
make[3]: *** [generate_extra_defs] Error 1
make[3]: Leaving directory
`/var/tmp/portage/gtkmm-2.6.4/work/gtkmm-2.6.4/tools/extra_defs_gen'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/gtkmm-2.6.4/work/gtkmm-2.6.4/tools'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/gtkmm-2.6.4/work/gtkmm-2.6.4'
make: *** [all] Error 2

!!! ERROR: dev-cpp/gtkmm-2.6.4 failed.
!!! Function gnome2_src_compile, Line 48, Exitcode 2
!!! compile failure
!!! If you need support, post the topmost build error, NOT this status message.
Comment 2 chris 2005-09-21 08:53:05 UTC
I found a possible solution, I'm trying it now.

"emerge glibmm gtkmm"

I guess glibmm should be emerged before gtkmm.
Comment 3 chris 2005-09-21 08:59:26 UTC
(In reply to comment #2)
> I found a possible solution, I'm trying it now.
> 
> "emerge glibmm gtkmm"
> 
> I guess glibmm should be emerged before gtkmm.

It would normally fail after 20 seconds or so, and it's been going on GTKMM for 
a few minutes now. Hooray!
Comment 4 chris 2005-09-21 09:02:02 UTC
ding ding ding!

It worked!

so to round things up, if GTKMM is failing as it was for me, emerging glibmm 
before gtkmm seems to be a workaround.
Comment 5 Pupeno 2005-09-21 11:05:04 UTC
I had problems emerging gtkmm deu to failing to find glibmm, maybe glibmm 
should be in the dependency list of gtkmm ? 
Comment 6 chris 2005-09-21 14:37:25 UTC
Yes, glibmm needs to be added as a dependency of gtkmm.
Comment 7 Aaron Walker (RETIRED) gentoo-dev 2005-09-21 22:25:50 UTC
(In reply to comment #6)
> Yes, glibmm needs to be added as a dependency of gtkmm.

Pasted straight from the gtkmm-2.6.4 ebuild itself:

RDEPEND=">=dev-cpp/glibmm-2.6
        >=x11-libs/gtk+-2.6
        >=dev-libs/libsigc++-2.0
        >=dev-libs/atk-1.9.1"

So... glibmm is a listed dependency.
Comment 8 chris 2005-09-22 04:17:44 UTC
Interesting... I wonder why it didn't emerge glibmm before it tried gtkmm then.
Comment 9 Aaron Walker (RETIRED) gentoo-dev 2005-09-22 06:19:49 UTC
(In reply to comment #8)
> Interesting... I wonder why it didn't emerge glibmm before it tried gtkmm then.

Judging by the error message (which I must've missed before), glibmm was already
installed.  The problem was that an updated libsigc++ came out after your
compiled glibmm.  Re-merging glibmm solved the problem.
Comment 10 Sean E Russell 2006-08-13 17:51:25 UTC
Hey,

No matter how I phrase this, it is going to sound like a rant.  I suppose it is, but I think the main thing I'm trying to ask is why this situation occurs, and to point out that it really is a serious defect in Portage.

Why isn't this sort of thing caught by revdep-rebuild, or by portage itself?  The number of esoteric commands that users have to remember to run when upgrading a package is getting increasingly longer.  First, it was just fix_libtool_files.sh(*), then revdep-rebuild, and unless revdep-rebuild gets smart enough to handle things like this, it now looks like we'll need another tool to catch this sort of crap.  The alternative is to just keep fumbling around in the dark, hoping somebody else has figured out the answer to cryptic problems.

Users are playing Russian Roulette when upgrading packages about the stability of their system.  They don't know what will end up broken, and they often have no idea -- when something does break -- what they have to do to fix it.  Seriously -- this sort of problem happens far too often.

I firmly believe that the resolution to this bug, "RESOLVED INVALID" is incorrect: this illustrates a defect in Portage, and *should* be fixed.


(*) Which, it looks like, is at least being run every time gcc is upgraded -- an improvement.