creating ./config.status creating Makefile creating rep-gtk.spec creating config.h mkdir gtk-2 /usr/lib/rep/i686-pc-linux-gnu/libtool --mode=compile gcc -c -DHAVE_CONFIG_H -I. -O2 -g -pipe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/lib/rep/i686-pc-linux-gnu -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -DORBIT2=1 -pthread -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/freetype2/config -I/usr/include/libxml2 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/freetype2/config -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include rep-types.c /usr/lib/rep/i686-pc-linux-gnu/libtool --mode=compile gcc -c -DHAVE_CONFIG_H -I. -O2 -g -pipe -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include -I/usr/lib/rep/i686-pc-linux-gnu -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libglade-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libxml2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -DORBIT2=1 -pthread -I/usr/include/libgnome-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gconf/2 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -DORBIT2=1 -pthread -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/gtk-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/bonobo-activation-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/freetype2/config -I/usr/include/libxml2 -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/freetype2/config -I/usr/include/gtk-2.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include rep-gtk.c libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make: *** [rep-gtk.lo] Error 1 make: *** Waiting for unfinished jobs.... libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' make: *** [rep-types.lo] Error 1 !!! ERROR: x11-libs/rep-gtk-0.18 failed. !!! Function src_compile, Line 47, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
No idea if the mass of repeating include flags above is a symptom or not. Portage 2.0.51-r3 (default-linux/x86/2004.2, gcc-3.4.2, glibc-2.3.4.20041102-r0, 2.6.9-gentoo-r1 i686) ================================================================= System uname: 2.6.9-gentoo-r1 i686 Pentium III (Coppermine) Gentoo Base System version 1.6.5 ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.59-r5 Automake: sys-devel/automake-1.8.5-r1 Binutils: sys-devel/binutils-2.15.92.0.2-r1 Headers: sys-kernel/linux26-headers-2.6.8.1-r1 Libtools: sys-devel/libtool-1.5.2-r6 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-O2 -g -pipe" CHOST="i686-pc-linux-gnu" COMPILER="" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control"CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -mcpu=i686 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache cvs digest distlocks notitles sandbox sfperms userpriv" GENTOO_MIRRORS="http://gentoo.osuosl.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="X acl alsa apm avi berkdb bitmap-fonts cdr cjk crypt cscope cups doc dvd dvdr emacs encode esd f77 faad fam flac foomaticdb fortran gcj gdbm gif gmp gnome gstreamer gtk gtk2 gtkhtml guile hal howl imagemagick imlib ipv6 jpeg junit ldap libg++ libwww mad mbox mikmod mmx mng motif mozilla mpeg ncurses nls nptl objc oggvorbis opengl pam pcre pdflib perl png postgres quicktime samba sdl spell sse ssl svg tcpd tetex threads tiff truetype unicode wmf x86 xml2 xv xvid zlib"
See also http://forums.gentoo.org/viewtopic.php?t=238312&highlight=repgtk
I guess when you need something bad enough, you find the solution yourself ;) The problem was the dependency between librep and rep-gtk and the ltmain.sh librep installs. librep configures an ltmain.sh script to compile with the compiler argument "i686-pc-linux-gnu-gcc" while rep-gtk uses "gcc". Its the difference in naming which causes this --tag inference bug. The solution is to ensure the libtool argument for librep and rep-gtk is the same. Attached is a patch which sets export CC="gcc" in librep's ebuild so that it matches rep-gtk and sawfish. The librep patch also incorporates Debians libtool patch and the ebuild also installs Debian's manpages.
Created attachment 45300 [details, diff] librep-0.18.patch
Created attachment 45301 [details, diff] rep-gtk-0.18.patch
Created attachment 45302 [details, diff] sawfish-1.3.2004120.patch
the CC tweaks to the librep and sawfish work for amd64 (ie, setting CC=gcc in the ebuild).
Created attachment 48438 [details, diff] librep-libtool.patch This bug is really a dupe of bug #68063, which is marked a dupe of #67692. The same fix for that can be applied to librep, except librep doesn't provide the original ltmain.in, only the generated ltmain.sh, so that needs to be patched instead. rep-gtk and sawfish don't need any modifications (nothing that has anything to do with this bug, anyway).
Um, hey, when is the ebuild going to be patched? It's been like this for weeks now.
From comments on bug 77921 it appears that rep-gtk like some other packages includes its own libtool, the output of emerge appears to be running /usr/lib/rep/i386-pc-linux-gnu/libtool when it apparently should be running /usr/bin/libtool Please see comments on bug 77921 and the files I have attached there. Thanks, Adam
The workaround described in bug 81260 works for rep-gtk also.
rep-gtk doesn't provide its own libtool, librep does. Since /usr/bin/libtool and /usr/lib/rep/*/libtool may have stored different configurations, is it really a good idea to use /usr/bin/libtool instead of patching /usr/lib/rep/*/libtool?
You should ask the maintainers of libtool.
Maintainers of libtool think that including libtool in other packages is stupid - see http://bugs.gentoo.org/show_bug.cgi?id=77921#c17
I don't care who wins the argument as long as the problem gets FIXED.
Hmm, seems there may be a problem of a different sort. I just hit this bug 300+ compiles in to a system rebuild. I'm surprised the ebuild hasn't been updated for six months, too. Can the build be working sporatically or is everybody downloading the patches every time it's compiled?
Ok, I'm fine with this if it goes away. After a lot of research there have been sportatic problems with this over the years. Apparently devlopment for sawfish (sawfish *IS* the only dependency for rep-gtk in the gentoo tree), has not been ongoing since the middle of 2003 and sawfish-themes has never progressed above the 0.0.1 level. <= My attempt at political correctness. Since I haven't used sawfish since Mandrake 8.1, I removed both from my tree and have no dependencies for librep or rep-gtk. For me this is fixed, thanks.
Sorry, wasn't trying to start an argument. If a symlink for libtool should fix things on an otherwise fine system, no complaints from me. In reply to the last comments, the CC environment variable used to be set with older gcc ebuilds (if I recall correctly), so that's why it used to work, but doesn't anymore.
Rebuilt from scratch today, still broken.
Aron, what is your take on the solution presented in comment 4, 5 and 6? With your permission, I'll commit this fix to portage. If I don't hear back within a week or so, I'll also commit it to portage.
Any update ? will it make it into portage ?
Created attachment 61565 [details] librep-libtool diff between working and broken rep-gtk-compile. Have one machine where it works and another where it does not work. On the working one, sawfish is used for longer now, and dates of /var/db/pkg/dev-libs/librep-0.17/* are 'Apr 30 2004'. On the broken one, want sawfish to install the very first time, so librep too. The difference is in the /usr/lib/rep/i686-pc-linux-gnu/libtool as stated in comment 3. To see it, i did: $ ebuild librep-0.17.ebuild install $ diff /usr/lib/rep/i686-pc-linux-gnu/libtool /var/tmp/portage/librep-0.17/image/usr/lib/rep/i686-pc-linux-gnu/libtool <my output is attached> To get rep-gtk compiled right now i've added a pkg_setup() to rep-gtk-0.18-r1.ebuild, but the real fix imo might be the patch in comment 8 for the librep-libtool: pkg_setup() { eval $(grep '^CC=.*gcc' /usr/lib/rep/${CHOST}/libtool) }
*** Bug 96808 has been marked as a duplicate of this bug. ***
Sorry I haven't been paying attention to this, guys. I quit using sawfish a while ago in favor of ion3 and haven't been maintaining it well since then. I think the correct solution here is simply to set CC prior to calling econf or configure for librep, rep-gtk and sawfish: CC=$(tc-getCC) econf ... In my tests this seems to solve the problem, and I've committed it to cvs now. Please re-open this bug if the problem persists for you. http://www.gentoo.org/cgi-bin/viewcvs.cgi/dev-libs/librep/librep-0.17-r1.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup http://www.gentoo.org/cgi-bin/viewcvs.cgi/x11-libs/rep-gtk/rep-gtk-0.18-r2.ebuild?rev=1.1&content-type=text/vnd.viewcvs-markup
This won't work if a user does CC=gcc emerge librep; emerge rep-gtk or, similarly, emerge librep; CC=gcc emerge rep-gtk (That may seem stupid, but it's reasonable; one example: the user could have been trying to build a bunch of stuff with CC set because another package (yes, a broken one) needed it, only to run out of disk space, into a system lockup, or anything else, when rep-gtk is being built. Then, that user fixes up the systen and runs emerge --resume (without setting CC again, because that other package that needed it is installed already). Besides, it's valid AFAIK even if there wasn't a reason for it.) Though, it should fix things for most situations, and works here, so thanks for that. And just say so if you don't want to handle those two situations :)
(In reply to comment #25) > And just say so if you don't want to handle those two situations :) There are lots of ways you can break a Gentoo system by changing variables between builds. Not going to handle it.
*** Bug 100534 has been marked as a duplicate of this bug. ***
