Bug 132435 - Building gtkhtml3 srpm creates dependancy on installed gtkhml3
Building gtkhtml3 srpm creates dependancy on installed gtkhml3
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Alexandre Oliva
: 132179 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2004-09-13 09:45 EDT by Aaron Gaudio
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-04-30 14:11:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Aaron Gaudio 2004-09-13 09:45:08 EDT
Description of problem:
I have gtkhtml3-3.1.16-2 installed when trying to build the srpm for
gtkhtml3-3.3.0-3. The resultant binary rpm contains a dependancy
on libgtkhtml-3.1.so.10, which is part fo the 3.1.16 release.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Install gtkhtml3-3.1.16-2
2. Rebuild the gtkhtml3-3.3.0-3 srpm.
3. Attempt to install the gtkhtml3-3.3.0-3 binary rpms.
Actual results:
Failed dependancies: libgtkhtml-3.1.so.10 is needed by gtkhtml3-3.3.0-3

Expected results:
gtkhtml3-.3.3.0-3 only depends on its internal libgtkhtml shared library.

Additional info:
This is a similar bug as 132179 filed against evolution-data-server.
Both may be caused by a libtool snafu.
Comment 1 Aaron Gaudio 2004-09-13 11:11:54 EDT
Okay, this has to be a libtool bug, I just encountered the same
problem with libgal2. I won't change the component immediately, but if
you feel like it, this and 132179 should probably be reassigned/duped
to a libtool bug.
Comment 2 Dave Malcolm 2005-03-28 13:29:15 EST
(Fixing bug title)

It may be a bug in the way gtkhtml3 is using the autotools, rather than a bug in
libtool itself (perhaps a systematic error in the way that these projects are
writing their Makefile.am files?)

Assigning to libtool for now

Comment 3 Alexandre Oliva 2005-03-28 15:02:44 EST
AFAICT this is fixed in rawhide libtool.  gtkhtml3 uses
LIBTOOL=/usr/bin/libtool, a use that, in spite of being unsupported, sometimes
works, and has the benefit of getting packages to automatically use the latest
copy of libtool, for better or for worse.  Other packages that use libtool as
intended (i.e., use an internal copy of libtool) may need explicit libtoolize
--force and update of libtool.m4 before %configure (or, ideally, a %patch that
produces the equivalent effect of doing the updates using a known-good version
of libtool).

(Dave, as for bug management, it would probably have been better to file a bug
against libtool, marked as blocking this bug and bug 132179, such that you could
keep track of progress in the libtool issue while retaining ownership of the
bugs reported against your packages.  The way it stands now, I have to close one
of them as a dupe of the other.)
Comment 4 Alexandre Oliva 2005-03-28 15:03:22 EST
*** Bug 132179 has been marked as a duplicate of this bug. ***
Comment 5 David Juran 2005-03-28 15:20:07 EST
I still see this bug with libtool-1.5.14.multilib2-6 and gtkhtml3-3.6.1-1. When
rebuilding the gtkhtml3 src rpm, I getting a dependency on my installed
gtkhtml3-3.5.7-1. As far as I see this dependency occurs when, during the
install phase when libgnome-gtkhtml-editor-3.6.so is relinked. Am I missing
something or could we reopen this bug?
Comment 6 Alexandre Oliva 2005-03-29 17:35:16 EST
Here's the link line for libgnome-gtkhtml-editor-3.6.so I get:

gcc -shared  .libs/editor-control-shlib.o -Wl,--whole-archive
./.libs/libgnome-gtkhtml-editor.a -Wl,--no-whole-archive  -L/usr/X11R6/lib64
-L/var/tmp/gtkhtml-3.6.1-root/usr/lib64 -L/usr/lib64 -lgtkhtml-3.6 -lgnomeui-2
-lSM -lICE -lgnomeprintui-2-2 -lgnomeprint-2-2 -lglade-2.0 -lbonoboui-2 -lxml2
-lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0
-lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2
-lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 
-m64 -pthread -m64 -mtune=nocona -Wl,--export-dynamic -pthread -Wl,-soname
-Wl,libgnome-gtkhtml-editor-3.6.so -o .libs/libgnome-gtkhtml-editor-3.6.so

It correctly lists /var/tmp/gtkhtml-3.6.1-root/usr/lib64 before /usr/lib64, and
thus gets the right binary for -lgtkhtml-3.6, whose SONAME I modified by means
of a patch for src/Makefile.in, adding -release test to the LDFLAGS of
libgtkhtml.   The detected dependencies for the binary rpms, as well as the
SONAME encoded in libgnome-gtkhtml-editor-3.6.so, were correct, i.e., they
listed libgtkhtml-3.6-test.so.

I'll need more info to be able to duplicate and fix the problem.  Make sure you
don't have LD_LIBRARY_PATH set, and that you don't have a link to the old
libgtkhtml3 lib in say /usr/X11R6/lib64 (or /lib, if you're on a non-lib64 host).
Comment 7 David Juran 2005-03-30 13:59:52 EST
And here my link line differs slightly, (except beeing for IA32)
In the link line that is produced on my system I get a
"-L/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../" early on which drags in the
old lib. So the question is, where does this come from? I've pasted the relevant
piece of my build log below.

/usr/bin/libtool --mode=install /usr/bin/install -c 

libtool: install: warning: relinking `libgnome-gtkhtml-editor-3.6.la'

(cd /home/david/rpm/BUILD/gtkhtml-3.6.1/components/html-editor; /bin/sh 

/usr/bin/libtool  --tag=CC --mode=relink gcc -DXTHREADS -D_REENTRANT
-DXUSE_MTSAFE_API -DORBIT2=1 -pthread -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/libgnomeui-2.0
-I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0
-I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0
-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/libxml2
-I/usr/include/libgnomeprint-2.2 -I/usr/include/libgnomeprintui-2.2
-I/usr/include/libglade-2.0 -DICONDIR="/usr/share/gtkhtml-3.6/icons"
-DGTKHTML_DATADIR="/usr/share/gtkhtml-3.6" -DGNOMELOCALEDIR="/usr/share/locale"
-g -pipe -m32 -march=i386 -mtune=pentium4 -Wall -Wmissing-prototypes -o
libgnome-gtkhtml-editor-3.6.la -rpath /usr/lib/gtkhtml -avoid-version -module
editor-control-shlib.lo ../../src/libgtkhtml-3.6.la -Wl,--export-dynamic
-pthread -L/usr/X11R6/lib -lgnomeui-2 -lSM -lICE -lgnomeprintui-2-2
-lgnomeprint-2-2 -lglade-2.0 -lbonoboui-2 -lxml2 -lpthread -lz -lgnomecanvas-2
-lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0 -lgtk-x11-2.0 -lgdk-x11-2.0
-latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgnomevfs-2 -lbonobo-2 -lgconf-2 -lbonobo-activation -lORBit-2 -lm
-lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 libgnome-gtkhtml-editor.la
-inst-prefix-dir /var/tmp/gtkhtml-3.6.1-root)

libtool: link: warning:
`/usr/lib/gcc/i386-redhat-linux/4.0.0/../../..//libpopt.la' seems to be moved
libtool: link: warning:
`/usr/lib/gcc/i386-redhat-linux/4.0.0/../../..//libxml2.la' seems to be moved
libtool: link: warning:
`/usr/lib/gcc/i386-redhat-linux/4.0.0/../../..//libgailutil.la' seems to be moved

gcc -shared  .libs/editor-control-shlib.o -Wl,--whole-archive
./.libs/libgnome-gtkhtml-editor.a -Wl,--no-whole-archive 
-L/usr/lib/gcc/i386-redhat-linux/4.0.0/../../../ -L/usr/X11R6/lib
-L/var/tmp/gtkhtml-3.6.1-root/usr/lib -L/usr/lib -lgtkhtml-3.6 -lgnomeui-2 -lSM
-lICE -lgnomeprintui-2-2 -lgnomeprint-2-2 -lglade-2.0 -lbonoboui-2 -lxml2
-lpthread -lz -lgnomecanvas-2 -lgnome-2 -lpopt -lart_lgpl_2 -lpangoft2-1.0
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lpangoxft-1.0
-lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgnomevfs-2 -lbonobo-2 -lgconf-2
-lbonobo-activation -lORBit-2 -lm -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 
-pthread -m32 -march=i386 -mtune=pentium4 -Wl,--export-dynamic -pthread
-Wl,-soname -Wl,libgnome-gtkhtml-editor-3.6.so -o
Comment 8 Alexandre Oliva 2005-04-04 14:22:52 EDT
Ok, got it on i686 too...  This was a tricky one.  The problem was that, when
constructing the list of dependencies for a libtool library that was about to be
linked in, we assumed the order of -L flags needed to get further dep libs
linked in didn't matter much, and just pushed them all onto a list that was
later reversed when passed to the compiler command line.  So, when we found that
-lgtkhtml-3.6 needed /usr/lib/gcc/i386-redhat-linux/4.0.0/../../../libpopt.la,
we went ahead and added -L/usr/lib/gcc/i386-redhat-linux-4.0.0/../../.. to the
list, after -lgtkhtml-3.6 and the -L flags added to make sure the proper version
thereof was linked in.  When the list was reversed, the -L flag for libpopt,
that happened to be equivalent to -L/usr/lib, was moved to the front, so the
installed libgtkhtml-3.6 was linked in.

Can you please confirm that this patch (to be applied in /usr/bin/libtool) fixes
the problem for you?

--- ltmain.in.~1.334.2.65.~	2005-03-16 14:34:33.000000000 -0300
+++ ltmain.in	2005-04-04 14:59:26.000000000 -0300
@@ -2872,7 +2872,7 @@ EOF
 	      case " $deplibs " in
 	      *" $path "*) ;;
-	      *) deplibs="$deplibs $path" ;;
+	      *) deplibs="$path $deplibs" ;;
 	  fi # link_all_deplibs != no

Comment 9 Alexandre Oliva 2005-04-04 14:53:53 EDT
Err...  The patch above introduces another subtle error.  This one should work

--- ltmain.in.~1.334.2.65.~	2005-03-16 14:34:33.000000000 -0300
+++ ltmain.in	2005-04-04 15:52:43.000000000 -0300
@@ -2867,12 +2867,12 @@ EOF
 	      *) continue ;;
 	      case " $deplibs " in
-	      *" $depdepl "*) ;;
-	      *) deplibs="$depdepl $deplibs" ;;
+	      *" $path "*) ;;
+	      *) deplibs="$path $deplibs" ;;
 	      case " $deplibs " in
-	      *" $path "*) ;;
-	      *) deplibs="$deplibs $path" ;;
+	      *" $depdepl "*) ;;
+	      *) deplibs="$depdepl $deplibs" ;;
 	  fi # link_all_deplibs != no
Comment 10 David Juran 2005-04-05 05:18:50 EDT
Yes, the patch in comment 9 solved the problem (-: 
Comment 11 Miloslav Trmač 2005-04-29 15:46:49 EDT
This looks like it shouldn't be in NEEDINFO, sorry if I missed something.

Note You need to log in before you can comment on or make changes to this bug.