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) gtk-engines-0.11-9 (rawhide) How reproducible: Always 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 wraps) 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 54 odir=/usr/share/info 107 checking for gtk_style_set_prop_experimental in -lgtk... yes (errors-->) 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 results checking for ANSI C header files... yes [...] checking for getpagesize... yes checking for working mmap... yes Additional info: 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, BUILD/gtk-engines-011/config.log shows: 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+ ***]), 31 $GTK_LIBS) 32 33 # Checks for header files. 34 AC_HEADER_STDC 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 problem.
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 to -lgtk. 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 or elsewhere. - Maybe you are using the gtkxft "anti-aliased fonts for GTK+ 1" hack? That often produces strange errors. Regards, Owen
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 the build. 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 glib-1.2.10-5 glib-devel-1.2.10-5 gtk+-1.2.10-11 gtk+-devel-1.2.10-11 (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 installed versions. 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 $ ./hello Hello, world! $ldd 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 report. 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 via /usr/share/aclocal/gtk.m4 GTK_LIBS=`$GTK_CONFIG $gtk_config_args --libs` and through a long chain, this eventually results (e.g.) in the following link, which does 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 DB42A60E gpg: Good signature from "Red Hat, Inc <security@redhat.com>" ) results in: $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 matched While ldd on both binaries shows that they are not linking in -lgdk automatically. (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.)