Building GTK on OSX and Problems with libiconv

Ok, this i maybe a bit special, but maybe it helps someone out there. I am on the way to build GTK+ on OSX using “jhbuild”, following a good instruction:

http://live.gnome.org/GTK%2B/OSX/BuildInstructions

Coming to the point where to build glib, the process exits with following error message:

gconvert.c:55:2: error: #error GNU libiconv not in use but included iconv.h is from libiconv

First the library is on the system; we can find it easily with

$ locate libiconv

Trying to link the system library to the one found provided by xcode failed into strange error messages. So i decided to re-build the libiconv by hand as “root” from source:

$ cd /usr/local/src/

Getting from http://www.gnu.org/software/libiconv/ the latest version (currently 1.13.1) with

$ wget http://ftp.gnu.org/pub/gnu/libiconv/libiconv-1.13.1.tar.gz
$ tar zxvf libiconv-1.13.1.tar.gz

Now the configuring, make and install phase:

$ ./configure
$ make
$ make install

This builds the latest version of libiconv for me. Final step was to replace the current version in

/usr/lib

and to go on with the GTK+ process.

Tags: , , ,

15 Responses to “Building GTK on OSX and Problems with libiconv”

  1. Florian Feldhaus Says:

    Why do you need to compile GTK+ on your own? Using MacPorts is a much easier solution in most cases. Only if you need to change something in the GTK sourcecode or if you need a version not provided through MacPorts I would consider building it myself…

  2. Jesko Merkel Says:

    Hi Florian,

    among other the most striking reasons are the massive duplication of libs and binaries on the system. MacPorts ships everything with it self, this leads to confusen for its self and for me when compiling own stuff. The other striking reason is that i favor native-OSX builds over X11 builds.
    Maybe these two given reasons are outdated, since i didn’t tried fink and MacPort for a long while, but you see they screwed my system up once and this will not happen again.

    Jesko

  3. Florian Feldhaus Says:

    Hi Jesko,

    I can understand your reasons. I had to struggle with MacPorts a lot in recent years, but today it seems to be quite reliable and doesn’t mess with your system. All MacPorts package are kept seperate from the system ones and if you uninstall them, your system is back in the original state. Also the native-OSX builds are possible now by using the variants +no_x11 and +quartz.

  4. Bloomy Says:

    I’m a newbie at this, so I followed all the steps and so far so go. However, the step where you say to replace the current version in /usr/lib , what exactly should I be copying to /usr/lib?

  5. Florian Feldhaus Says:

    Hi Bloomy!

    ‘make install’ places the new build files into /usr/local/lib. I guess it should be sufficient to overwrite the files in /usr/lib with the new built files from /usr/local/lib . Check afterwards, that the symlink from libiconv.dylib to libiconv.2.dylib is correct. You may just ommit libiconv.dylib when copying the files!

  6. Jesko Merkel Says:

    Hi Bloomy,

    yes, thats a good point in this game. First let me remind you on the comment by Florian that MacPorts is way better this times than in the past and you should have some good reasons to compile GTK+ on your own. Now to the answer: There are 3 options coming to my mind:
    1) as you said you can replace the system lib in /usr/lib but it is the system lib and other binaries may depend on it and may fail to execute due to whatever. So at least make sure you keep the original version, so you can put it back in case things screw up.
    2) use the OSX library preload functionality of dyld via the shell variables DYLD_LIBRARY_PATH or DYLD_INSERT_LIBRARIES while keep in mind that setting the variable DYLD_PRINT_LIBRARIES helps debugging.
    3) use the “–prefix=” for the configuring stage of libiconv and set it to the GTK path e.g. /Users/bloomy/gtk/inst or /var/root/gtk/inst

    cheers,
    Jesko

  7. Fu Chen Says:

    Hi Jesko,

    Thanks for your conclusion. It helps a lot.

    Fu

  8. Thijs Says:

    Overwriting the system libiconv likely breaks other software that depends on it. I experienced this with VLC that crashed when it couldn’t find the apple libiconv (osx 10.6.4). I think I’m going for Jesko’s third option, thanks.

  9. Hamish Says:

    I had this problem too and found running the following fixed it for me

    jhbuild build libiconv

  10. cico Says:

    Jesko’s third option (and a shell reboot) worked like a charm, thanks a gazillion!

  11. Hamish Says:

    Hmm. I reinstalled and “jhbuild build libiconv” didn’t work this time. Jesko’s solution 3 worked nicely.

  12. Jesko Merkel Says:

    Just a comment if someone has problems with glib and libiconv: I had some problems building glib on OS X 10.6 and found out that it works if going back to glib version 2.22.5. Well, did had time to figure out why, but it works for me.

  13. Nikhil Says:

    Hi Jesko,

    I am a newbie with my first Mac running across this problem.

    Could you explain how to carry out option 3 step-by-step?

    jhbuild build libiconv does not work

  14. Jesko Merkel Says:

    I recommend to stick to MacPorts. It will be the easiest way. Only for some really good reasons you should think of compiling such libraries.

    Cheers,

    Jesko

  15. Marius Says:

    Thanks a lot, your last tip (replace files in /usr) saved my day!

Leave a Reply