Bug 109673 - Core 1 ships with misbuilt gtk+-1.2.10-28.1.i386.rpm, libgdk-1.2.so.0
Summary: Core 1 ships with misbuilt gtk+-1.2.10-28.1.i386.rpm, libgdk-1.2.so.0
Alias: None
Product: Fedora
Classification: Fedora
Component: gtk+
Version: 1
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-11-10 21:01 UTC by Thomas Sailer
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Clone Of:
Last Closed: 2004-09-22 06:13:02 UTC

Attachments (Terms of Use)

Description Thomas Sailer 2003-11-10 21:01:26 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)

Description of problem:
libXi is not mentioned in the dynamic section of libgdk.so as NEEDED
(objdump -x /usr/lib/libgdk.so). This means that most existing gtk+
applications won't start, instead complaining "relocation error:
/usr/lib/libgdk-1.2.so.0: undefined symbol: XListInputDevices".
XListInputDevices is contained in libXi

Note that there is nothing wrong in the _source_ RPM, however the
_binary_ RPM is misbuilt, because of a bug in libtool-1.5-8. See Bug

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

How reproducible:

Steps to Reproduce:
1. objdump -x /usr/lib/libgdk.so


Additional info:

Comment 1 Owen Taylor 2003-11-10 21:11:13 UTC
What sort of "most existing apps"? - I'd expect any GTK+
app built against Red Hat since 1998 or so to have a DT_NEEDED 
against libXi itself:

$ gtk-config --libs gtk
-L/usr/lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib
-ldl -lXi -lXext -lX11 -lm

Which will cover this problem up. Certainly works fine with
all the GTK+-1.2 apps I have here.

Comment 2 Thomas Sailer 2003-11-10 22:46:06 UTC
I've got a couple apps I've packaged against the then current RedHat release: 
rpm -qi qiv 
Name        : qiv                          Relocations: (not relocateable) 
Version     : 1.0.1                             Vendor: Adam Kopacz / kLoGraFX 
Release     : 1                             Build Date: Wed Mar  3 00:41:32 1999 
Install Date: Wed Mar  3 00:48:51 1999      Build Host: playstation.ampr.org 
Group       : X11/Applications/Graphics     Source RPM: qiv-1.0.1-1.src.rpm 
Size        : 45615                            License: GNU GENERAL PUBLIC LICENSE 
Signature   : (none) 
Packager    : Thomas Sailer <sailer@ife.ee.ethz.ch> 
Summary     : Quick Image Viewer 
Description : 
Quick Image Viewer 
Dynamic Section: 
  NEEDED      libgdk_imlib.so.1 
  NEEDED      libgtk-1.2.so.0 
  NEEDED      libgdk-1.2.so.0 
  NEEDED      libgmodule-1.2.so.0 
  NEEDED      libglib-1.2.so.0 
  NEEDED      libdl.so.2 
  NEEDED      libXext.so.6 
  NEEDED      libX11.so.6 
  NEEDED      libm.so.6 
  NEEDED      libc.so.6 
Anyway, have you looked at the stdout/stderr output of rpmbuild --rebuild 
gtk+*src.rpm? There are quite a lot of shell errors. These seem to be due to libtoolize 
--force not replacing all required files (eg. ltconfig remains the old version) 

Comment 3 Eneko Lacunza 2004-03-07 10:29:17 UTC

Owen, the problem is with apps that didn't use 'gtk-config --libs
gtk', but linked directly to libgtk. There seem to be some of them.

I have problems because of this with some own binaries. Not that it's
a problem for me to recompile, but there would be third parties with
problems running it (part of real-time graphics demos).

I think that it's clear that libgdk has broken dependencies, anyway.
Is there a way I can help to fix this issue? Or you're just fixing it
for FC2?

Thanks a lot.

Comment 4 Rex Dieter 2004-03-12 18:56:22 UTC
For me, the easiest fix was to patch the gtk+ specfile, and replace
make LIBTOOL=/usr/bin/libtool

%makeinstall LIBTOOL=/usr/bin/libtool

Comment 5 Matthias Clasen 2004-09-22 06:13:02 UTC
> the problem is with apps that didn't use 'gtk-config --libs
> gtk', but linked directly to libgtk.

gtk-config --libs is the only supported way to link against gtk+-1.2.
Apps which don't play by the rules have to look after themselves.

Comment 6 Rex Dieter 2004-09-22 13:03:22 UTC
FYI, see also bug #114587 (pretty much a dup of this one).

I'm sorry your consider it WONTFIX, because, IMO, shared libraries, in
this case:
should not contain undefined references, period.

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