Summary: | dev-cpp/gtkmm-2.6.4 emerge fails | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | chris <clauretano> |
Component: | [OLD] Unspecified | Assignee: | GNOME C++ Bindings Maintainers (OBSOLETE) <gnome-mm+disabled> |
Status: | RESOLVED INVALID | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
chris
2005-09-21 03:51:09 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. I found a possible solution, I'm trying it now. "emerge glibmm gtkmm" I guess glibmm should be emerged before gtkmm. (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! 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. I had problems emerging gtkmm deu to failing to find glibmm, maybe glibmm should be in the dependency list of gtkmm ? Yes, glibmm needs to be added as a dependency of gtkmm. (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. Interesting... I wonder why it didn't emerge glibmm before it tried gtkmm then. (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. 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. |