Red Hat Bugzilla – Bug 64081
srpm configure script links -lgtk to some generic tests
Last modified: 2008-05-01 11:38:02 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.2.19-kim.3 i486)
Description of problem:
The configure script for gtk-engines-0.11-3.src.rpm produces incorrect results
for several generic autoconf 2.13 tests, due to unresolved symbols from -lgtk.
Version-Release number of selected component (if applicable):
gtk-engines-0.11-3 (rh 7.2)
Steps to Reproduce:
1.$ rpm -i gtk-engines-0.11-3.src.rpm
2.[SPECS[$ rpmbuild -bc gtk-engines.spec 2>&1 | tee ~/build.log
Actual Results: Extract from build.log (line numbers added--note line skips and
37 Executing(%build): /bin/sh -e /var/tmp/rpm-tmp.56777
54 + ./configure i386-redhat-linux --prefix=/usr --exec-prefix=/usr --bindi
54 r=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --
54 includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --lo
54 calstatedir=/var --sharedstatedir=/usr/com --mandir=/usr/share/man --inf
107 checking for gtk_style_set_prop_experimental in -lgtk... yes
109 checking for ANSI C header files... no
117 checking for getpagesize... no
118 checking for working mmap... no
Expected Results: After patching gtk-engines-0.11-9.src.rpm, I get the expected
checking for ANSI C header files... yes
checking for getpagesize... yes
checking for working mmap... yes
This failure was also reproduced in gtk-engines-0.11-9.src.rpm (rawhide).
From the failing build gtk-engines-0.11-3.src.rpm build,
57 configure:2168: checking for gtk_style_set_prop_experimental in -lgtk
58 configure:2187: gcc -o conftest -O2 -mcpu=i486 conftest.c -lgtk -L/usr
58 /lib -L/usr/X11R6/lib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -
58 lXext -lX11 -lm 1>&5
59 configure:2218: checking how to run the C preprocessor
60 configure:2239: gcc -E conftest.c >/dev/null 2>conftest.out
61 configure:2298: checking for ANSI C header files
62 configure:2311: gcc -E conftest.c >/dev/null 2>conftest.out
63 configure:2378: gcc -o conftest -O2 -mcpu=i486 conftest.c -lgtk 1>&5
64 /usr/lib/libgtk.so: undefined reference to `gdk_property_get'
65 /usr/lib/libgtk.so: undefined reference to `gdk_string_to_compound_text'
273 /usr/lib/libgtk.so: undefined reference to `gdk_char_width_wc'
274 collect2: ld returned 1 exit status
and similarly for getpagesize and mmap.
The inclusion of -lgtk during the generic test for ansi headers is due to the
following lines from configure.in:
29 AC_CHECK_LIB(gtk, gtk_style_set_prop_experimental, ,
30 AC_MSG_ERROR([*** gtk_style_set_prop_experimental() not fou
30 nd; perhaps you have an old CVS version of GTK+ ***]),
33 # Checks for header files.
From the autoconf 2.13 documentation:
"ACTION-IF-FOUND is a list of shell commands to run if the link
with the library succeeds; ACTION-IF-NOT-FOUND is a list of shell
commands to run if the link fails. If ACTION-IF-FOUND is not
specified, the default action will add `-lLIBRARY' to `LIBS' and
define `HAVE_LIBLIBRARY' (in all capitals)."
So the result of the empty 3rd argument in line 29 of configure.in causes
LIBS="-lgtk" during the subsequent tests.
The attached patch is against gtk-engines-0.11-9.src.rpm (rawhide) and fixes the
Created attachment 55264 [details]
Fix link failures during generic configure tests caused by -lgtk
it's hard to say what is going wrong on your system (yes, gtk-engines
does rebuild...) but in any case, the fix is _not_ to remove linking
My guesses would be:
- Something is wrong with the GTK+ on your system. Try a rpm --qV
gtk+ and also check to see if you have a GTK+ in /usr/local/lib
- Maybe you are using the gtkxft "anti-aliased fonts for GTK+ 1"
hack? That often produces strange errors.
First note that both gtk-engines-0.11-3 and gtk-engines-0.11-9 were able to
*build* for me
successfully. The error was only in their configuration--and was not fatal to
So, first assuming that the error is in my environment (which is both logical
and the path
I went down first myself :-).
$ rpm -q glib glib-devel gtk+ gtk+-devel
(all built locally)
Early in troubleshooting, I rebuilt gtk+ and verified that both the .so files
and all of the .o files contained in the .a static archives were identical to my
I am unable to link hello, world! with -lgtk. I get that same errors that
showed up in the config.log.
But I am able to link hell, world! with -lgtk -lgdk. And I can do:
gcc hello.c `gtk-config --libs` -o hello
libgtk-1.2.so.0 => /usr/lib/libgtk-1.2.so.0 (0x4001a000)
libgdk-1.2.so.0 => /usr/lib/libgdk-1.2.so.0 (0x4013d000)
libgmodule-1.2.so.0 => /usr/lib/libgmodule-1.2.so.0 (0x40172000)
libglib-1.2.so.0 => /usr/lib/libglib-1.2.so.0 (0x40175000)
libdl.so.2 => /lib/libdl.so.2 (0x40199000)
libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x4019d000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x401a5000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x401b1000)
libm.so.6 => /lib/libm.so.6 (0x40255000)
libc.so.6 => /lib/libc.so.6 (0x40272000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
So, going back to gtk-engines--we get the info that I originally put in this bug
Are you able to get
"checking for ANSI C header files... yes"
during an unpatched configure?
As far as my patch goes, removing -gtk from LIBS during the generic configure
tests does not
remove it where its required in the build link:
This is because AM_PATH_GTK in configure.in sets GTK_LIBS
GTK_LIBS=`$GTK_CONFIG $gtk_config_args --libs`
and through a long chain, this eventually results (e.g.) in the following link,
not only include -lgtk but also the other necessary libs like -lgdk:
(extract from my patched gtk-engines-0.11-9.n build log)
170 /bin/sh ../libtool --mode=link gcc -O2 -mcpu=i486 -o libpixmap.la -rpa
170 th /usr/lib/gtk/themes/engines -module -avoid-version pixmap_theme_draw.
170 lo pixmap_theme_main.lo -L/usr/lib -lgdk_imlib -L/usr/lib -L/usr/X11R6/l
170 ib -lgtk -lgdk -rdynamic -lgmodule -lglib -ldl -lXi -lXext -lX11 -lm
171 mkdir .libs
172 rm -fr .libs/libpixmap.la .libs/libpixmap.* .libs/libpixmap.*
173 (cd . && ln -s pixmap_theme_draw.lo pixmap_theme_draw.o)
174 (cd . && ln -s pixmap_theme_main.lo pixmap_theme_main.o)
175 gcc -shared pixmap_theme_draw.lo pixmap_theme_main.lo -L/usr/lib -lgdk
175 _imlib -L/usr/X11R6/lib /usr/lib/libgtk.so /usr/lib/libgdk.so /usr/lib/l
175 ibgmodule.so /usr/lib/libglib.so -ldl -lXi -lXext -lX11 -lm -Wl,-soname
175 -Wl,libpixmap.so -o .libs/libpixmap.so
176 creating libpixmap.la
Confirmation that my installed libgtk-1.2.so seems sane.
Comparing my locally built version in /usr/lib with ../libgtk-1.2.so.0.9.1
( rh 7.2 precompiled binary shipped in gtk+-1.2.10-11.i386.rpm
MD5 sum OK: 0703079e0e4d862e5d3bbb00450e013f
gpg: Signature made Fri 07 Sep 2001 09:20:30 AM PDT using DSA key ID
gpg: Good signature from "Red Hat, Inc <firstname.lastname@example.org>" )
$diff <(nm -u --dynamic /usr/lib/libgtk-1.2.so.0.9.1 | grep gdk) <(nm -u
--dynamic ./libgtk-1.2.so.0.9.1 | grep gdk) && echo matched
While ldd on both binaries shows that they are not linking in -lgdk
(And if -lgtk was internally linked with -lgdk, then why would we need
`gtk-config --libs` at all?
Instead of just a bare link with -lgtk all the time?)
OK, I've checked into it and your diagnosis is correct, but its harmless
becasue the checks that break aren't needed anywhere in the code.
I've cleaned them up in GNOME CVS now, thanks. They will be fixed
in Red Hat packages if/when we pull new versions from upstream.
(Closing as RAWHIDE, as the closest resolution, but actually not
fixed in there.)