Bug 64081 - srpm configure script links -lgtk to some generic tests
srpm configure script links -lgtk to some generic tests
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: gtk-engines (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Owen Taylor
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-04-25 07:01 EDT by Ned Ulbricht
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-25 21:16:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fix link failures during generic configure tests caused by -lgtk (1.01 KB, patch)
2002-04-25 07:03 EDT, Ned Ulbricht
no flags Details | Diff

  None (edit)
Description Ned Ulbricht 2002-04-25 07:01:22 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.
Comment 1 Ned Ulbricht 2002-04-25 07:03:44 EDT
Created attachment 55264 [details]
Fix link failures during generic configure tests caused by -lgtk
Comment 2 Owen Taylor 2002-04-25 10:13:04 EDT
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
Comment 3 Ned Ulbricht 2002-04-25 17:19:26 EDT
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


Comment 4 Ned Ulbricht 2002-04-25 21:16:50 EDT
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?)
Comment 5 Owen Taylor 2002-10-31 19:01:44 EST
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.)

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