Bugzilla Bug 70514

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 an attachment (id=45300) [details]
librep-0.18.patch

Created an attachment (id=45301) [details]
rep-gtk-0.18.patch

Created an attachment (id=45302) [details]
sawfish-1.3.2004120.patch

the CC tweaks to the librep and sawfish work for amd64
(ie, setting CC=gcc in the ebuild).

Created an attachment (id=48438) [details]
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 an attachment (id=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. ***