Bug 64081
Summary: | srpm configure script links -lgtk to some generic tests | ||||||
---|---|---|---|---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Ned Ulbricht <nedu> | ||||
Component: | gtk-engines | Assignee: | Owen Taylor <otaylor> | ||||
Status: | CLOSED RAWHIDE | QA Contact: | |||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 7.2 | ||||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2002-04-26 01:16:55 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
Ned Ulbricht
2002-04-25 11:01:22 UTC
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>" ) 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.) |