After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 624471 - 'make' fails even though 'configure' is OK
'make' fails even though 'configure' is OK
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: .General
2.20.x
Other Linux
: Normal blocker
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2010-07-15 16:21 UTC by Sergei Steshenko
Modified: 2011-02-02 14:27 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
failing 'make' screen output (55.73 KB, application/x-gzip)
2010-07-15 16:25 UTC, Sergei Steshenko
Details
autogenerated script used to run 'configure' (7.92 KB, text/plain)
2010-07-15 16:27 UTC, Sergei Steshenko
Details
generated by 'configure' failing Makefile (51.66 KB, text/plain)
2010-07-15 16:43 UTC, Sergei Steshenko
Details
gtk-query-immodules-2.0 script as generated by build mechanism (5.19 KB, text/plain)
2010-07-19 23:50 UTC, Sergei Steshenko
Details

Description Sergei Steshenko 2010-07-15 16:21:27 UTC
I've been building gtk+ routinely for years using my AppsFromScratch.

Using exactly the same settings (to be seen in yet to be uploaded autogenerated 'configure' wrapper) I am able to build gtk+-2.6.16 with glib-2.22.5, gtk+-2.18.9 with glib-2.22.5.

This report is against gtk+-2.20.1 and glib-2.24.1; glib-2.24.1 also breaks build of gtk+-2.18.9 in the same manner, so I suspect the problem is somehow related to glib-2.24.1.
Comment 1 Sergei Steshenko 2010-07-15 16:25:44 UTC
Created attachment 165973 [details]
failing 'make' screen output
Comment 2 Sergei Steshenko 2010-07-15 16:27:02 UTC
Created attachment 165974 [details]
autogenerated script used to run 'configure'
Comment 3 Sergei Steshenko 2010-07-15 16:43:49 UTC
Created attachment 165975 [details]
generated by 'configure' failing Makefile
Comment 4 Sergei Steshenko 2010-07-15 23:09:30 UTC
Another odd thing.

If one looks into the attached https://bugzilla.gnome.org/attachment.cgi?id=165974 autogenerated 'configure' wrapper, he/she can see references to just one 'glib' version which is glib-2.24.1, and this is how it is supposed to.

When running 'make' after some time I also see references to glib-2.22.2, which I also have, but I told the build mechanism _nothing_ about it.

These are the files which have the references:

"
sergei@amdam2:~/junk> grep -r glib-2.22.2 /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1 | cut -d: -f1 | sort | uniq
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.so.0.2000.1 matches
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.so.0 matches
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.so matches
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs/libgtk-x11-2.0.so.0.2000.1 matches
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs/libgtk-x11-2.0.so.0 matches
Binary file /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs/libgtk-x11-2.0.so matches
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/libgdk-x11-2.0.la
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.la
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs/libgdk-x11-2.0.lai
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/libgtk-x11-2.0.la
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs/libgtk-x11-2.0.la
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs/libgtk-x11-2.0.lai
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/make.sh.new_log
sergei@amdam2:~/junk>
".

So how does the build mechanism find glib-2.22.2 and why ?

Please note that I install _nothing_ in system locations. Everything resides under
"
ls -ltr /mnt/sdb8/sergei/AFSWD_debug/install
lrwxrwxrwx 1 qemu users 22 2010-06-27 09:29 /mnt/sdb8/sergei/AFSWD_debug/install -> /mnt/sdb5/qemu/install
".

Please also note that before building

\rm -rf gtk+-2.20.1

is executed, i.e. everything is built from scratch.

Furthermore, 'configure' _refuses_ to accept glib-2.22.2 as too old.
Comment 5 André Klapper 2010-07-19 18:40:02 UTC
Okay, summarizing:

gtk+-2.20.1 does not build with glib-2.24.1.

(In reply to comment #1)
> Created an attachment (id=165973) [details]
> failing 'make' screen output

Cannot load module /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/modules/input/im-xim.la: /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/modules/input/.libs/im-xim.so: undefined symbol: g_realloc_n
/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/modules/input/im-xim.la does not export GTK+ IM module API: /mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/modules/input/.libs/im-xim.so: undefined symbol: g_realloc_n
make[3]: *** [gtk.immodules] Error 1
make[3]: Leaving directory `/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/modules/input'
make[2]: *** [all-recursive] Error 1

This fails as g_realloc_n () was introduced in glib 2.24 and something links against 2.22.

Did you try cleaning/removing the files that have references to glib 2.22?
Comment 6 Sergei Steshenko 2010-07-19 21:47:12 UTC
I found the root cause. Build process creates 'gtk+-2.20.1/gtk/gtk-query-immodules-2.0' file (using 'libtool' coming with the source).

This file contains the following line:

"
   107      LD_LIBRARY_PATH="/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gtk/.libs:/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk/.libs:/mnt/sdb8/sergei/AFSWD_debug/build/gtk+-2.20.1/gdk-pixbuf/.libs:/usr/lib:/mnt/sdb8/sergei/AFSWD_debug/install/pango-1.28.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/gcc-4.4.4/lib:/mnt/sdb8/sergei/AFSWD_debug/install/atk-1.30.0/lib:/mnt/sdb8/sergei/AFSWD_debug/install/cairo-1.8.10/lib:/mnt/sdb8/sergei/AFSWD_debug/install/pixman-0.18.2/lib:/mnt/sdb8/sergei/AFSWD_debug/install/libpng-1.2.43/lib:/mnt/sdb8/sergei/AFSWD_debug/install/glib-2.24.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/fontconfig-2.8.0/lib:/mnt/sdb8/sergei/AFSWD_debug/install/freetype-2.4.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/expat-2.0.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/libiconv-1.13.1/lib:/mnt/sdb8/sergei/AFSWD_debug/install/pcre-7.9/lib:$LD_LIBRARY_PATH"
".

The line is faulty _by_ _construction_ - this is because '/usr/lib' component is _before_ the supplied by user $LD_LIBRARY_PATH. I.e. the '/usr/lib' causes build mechanism to look for various things in system directories first instead of looking for them first in $LD_LIBRARY_PATH path supplied by user, as it is supposed to be.

I have worked around the problem the following way (everything is scripted):

1) 'make' is run and fails as described;
2) 'gtk+-2.20.1/gtk/gtk-query-immodules-2.0' is hacked by my build tool - the offending '/usr/lib' component is removed from the above line #107;
3) '\rm gtk+-2.20.1 /modules/input/*.lo' is executed so the failing 'make' step will for sure be re-executed;
4) 'make all' is run (simple 'make' could have been run, but my tool "prefers" unique 'make' targets).

In such a manner I can successfully build gtk+ and many other targets depending on it.

The described flaw affects _anybody_ having libraries in non-default locations.

I do not know whether it's a 'libtool' bug or 'gtk+' bug.
Comment 7 Sergei Steshenko 2010-07-19 21:55:05 UTC
Of course, in the end I run 'make install' - without hacking 'gtk+-2.20.1/gtk/gtk-query-immodules-2.0' it fails with the same unresolved symbol. But since 'gtk+-2.20.1/gtk/gtk-query-immodules-2.0' is already hacked earlier, 'make install' works just fine.
Comment 8 Sergei Steshenko 2010-07-19 22:05:39 UTC
FWIW, I didn't simply guess what/where the problem was, I set LD_DEBUG envirinment variable to 'all' and looked carefully where the binary invoked by 'gtk+-2.20.1/gtk/gtk-query-immodules-2.0' script (it's 'gtk+-2.20.1/gtk/.libs/gtk-query-immodules-2.0') looks for libraries. So I realized it was looking for 'glib' in system directories and then found the offending line #107.
Comment 9 Sergei Steshenko 2010-07-19 23:50:41 UTC
Created attachment 166186 [details]
gtk-query-immodules-2.0 script as generated by build mechanism
Comment 10 Ralf Wildenhues 2010-07-21 18:19:37 UTC
Looks like a libtool issue.  The root cause of this could be the same as this:
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7440/focus=7445>

bug-libtool thread corresponding to this bug:
<http://thread.gmane.org/gmane.comp.gnu.libtool.bugs/7447>
Comment 11 Javier Jardón (IRC: jjardon) 2011-02-02 14:27:13 UTC
Closing then