Re: [Gtk-osx-users] glib version error while building gimp

[Tim Chen <ht timchen gmail com>]

Yes, after wiping the ~/gtk and ~/Source director, I can build gegl successfully. woot!

Unfortunately, the story does not end there.

(I will try to describe things in detail so that maybe it would be helpful for other people interesting in compiling gimp on Mac.)

while building gimp, an error will appear

==============================
menus/Makefile.am:54: `%'-style pattern rules are a GNU make extension
plug-ins/common/Makefile.am:199: `%'-style pattern rules are a GNU make extension
/bin/sh: srcdir: command not found
/bin/sh: s/configure: No such file or directory
*** Error during phase configure of gimp: ########## Error running autoreconf -fis && $(srcdir)s/configure --prefix /Users/timchen/gtk/inst --libdir '/Users/timchen/gtk/inst/lib' --disable-python --without-x                           --without-dbus --without-gnomevfs --without-wmf --enable-binreloc  --disable-static *** [7/7] 
===============================

I am not sure the reason behind it, but I fix it by exiting to shell, then do the configuration there by

./configure --prefix /Users/timchen/gtk/inst --libdir '/Users/timchen/gtk/inst/lib' --disable-python --without-x  --without-dbus --without-gnomevfs --without-wmf --enable-binreloc  --disable-static --disable-mmx
(note that the flag *--disable-mmx* is somehow needed to avoid some compile error later)

 then I exit the shell and continue the building process and gimp is finally built. 

However, when I tried to launch gimp with ~/gtk/inst/bin/gimp The splash screen appear and it hangs with the subtitle

Starting Extensions
extension-script-fu

And when I terminated the process with ctrl + c, it shows

./gimp: terminated: Interrupt
/Users/timchen/gtk/inst/lib/gimp/2.0/plug-ins/script-fu terminated: Interrupt

My first guess was that there is some sort of bug with the pygtk, but it turns out that I can run several pygtk examples without problem. 

So, I am basically stuck here. Do you think it is related to the previous error in autoreconf?

thanks,
Tim


On Apr 19, 2011, at 1:04 PM, John Ralls wrote:

> 
> On Apr 18, 2011, at 9:08 PM, Tim Chen wrote:
> 
>> upon further investigation, I realized that the error actually happened while building glib
>> 
>> =============================
>> 
>> checking for iconv_open... no
>> checking for libiconv_open in -liconv... no
>> checking for iconv_open in -liconv... no
>> configure: error: *** No iconv() implementation found in C library or libiconv
>> *** Error during phase configure of glib: ########## Error running ./configure --prefix /Users/timchen/gtk/inst --libdir '/Users/timchen/gtk/inst/lib'  --disable-static ac_cv_c_bigendian=no --build=i486-apple-darwin  *** [2/12] 
>> 
>> ==============================
>> 
>> the corresponding error in config.log is
>> 
>> ==============================
>> 
>> configure:7345: checking for iconv_open
>> configure:7345: gcc -o conftest -arch i386 -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -I/Users/timchen/gtk/inst/include -I/Developer/SDKs/MacOSX10.6.sdk/usr/include -L/Users/timchen/gtk/inst/lib -L/Users/timchen/gtk/inst/lib -arch i386 -L/Developer/SDKs/MacOSX10.6.sdk/usr/lib -isysroot /Developer/SDKs/MacOSX10.6.sdk -mmacosx-version-min=10.6 -Wl,-headerpad_max_install_names -framework Carbon conftest.c  >&5
>> Undefined symbols for architecture i386:
>> "_iconv_open", referenced from:
>>     _main in ccP63cQa.o
>> ld: symbol(s) not found for architecture i386
>> collect2: ld returned 1 exit status
>> 
>> ==============================
>> 
>> I think this error is similar to http://sourceforge.net/mailarchive/message.php?msg_id=24905828 and probably means that it linked wrong version of libiconv 
>> 
>> Nevertheless, as posted in my last mail, I have already put
>> 
>> setup_sdk(target="10.6", sdk_version="10.6", architectures=["i386"])
>> 
>> in my .jhbuildrc-custom. I suppose doing so should have already fix the problem? 
>> 
> 
> No, the problem that that message (along with several others) addressed was that the symbol _libiconv_open is missing from the x86_64 image in Apple's distribution of libiconv. You're building i386, and the symbol _iconv_open is present in both the i386 and x86_64 images.
> 
> The new (since january) gtk-osx-build-setup.sh replaces the jhbuild stock bootstrap.modules with a replacement that builds a new libiconv regardless of architecture. I suspect what happened is that you ran jhbuild bootstrap *without* specifying the architecture to setup_sdk() and so built libiconv and gettext as x86_64, so there's no i386 image to link to. The safest thing to do at this point is to wipe everything and start over. Anything short of that will risk linkage problems in the several dependent libraries.
> 
> Regards,
> John Ralls
> 
> 
> 
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload 
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve 
> application availability and disaster protection. Learn more about boosting 
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Gtk-osx-users mailing list
> Gtk-osx-users lists sourceforge net
> https://lists.sourceforge.net/lists/listinfo/gtk-osx-users