gtk-osx-users Mailing List for GTK+ Mac OS X (Page 11)
Status: Beta
Brought to you by:
jralls
This list is closed, nobody may subscribe to it.
2009 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
(33) |
Aug
(12) |
Sep
(28) |
Oct
(1) |
Nov
(30) |
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(3) |
Feb
(22) |
Mar
(31) |
Apr
(49) |
May
(48) |
Jun
(16) |
Jul
(16) |
Aug
(42) |
Sep
(62) |
Oct
(11) |
Nov
(28) |
Dec
(16) |
2011 |
Jan
(11) |
Feb
(44) |
Mar
(43) |
Apr
(53) |
May
(54) |
Jun
(54) |
Jul
(15) |
Aug
(11) |
Sep
(8) |
Oct
(2) |
Nov
(4) |
Dec
(4) |
2012 |
Jan
|
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(2) |
2013 |
Jan
(7) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(8) |
Jul
(6) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(1) |
2014 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(18) |
Sep
|
Oct
|
Nov
|
Dec
(4) |
2015 |
Jan
(2) |
Feb
|
Mar
|
Apr
(13) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
|
Feb
(9) |
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Cliff S. <cs...@vb...> - 2011-04-26 14:53:16
|
Thanks very much. This is very useful. On Apr 26, 2011, at 9:45 AM, John Ralls wrote: > > On Apr 26, 2011, at 5:28 AM, Cliff Sharp wrote: > >> Good suggestions. >> >> My plan is to get Spice Client working on OSX with as little changes as possible for Phase One. That means using Gtk and X11 as it is now in Spice Client since both of these already work on OSX. In other words, just to port it to Darwin. For this phase I would not Cocoa'ize it. I am ASSUMING since OSX is Unix (Darwin) under the covers this would not be that difficult - of course I don't know how true or not this is. >> >> Then Phase Two would be to replace/port Gtk/X11, sound, and whatever else to work on OSX. Using OpenGL, Core Audio, etc - Cocoa'ize it. >> >> Phase Three would be to then get Phase Two working on iOS. >> >> To date I have most of the Spice dependent libraries at least building under Darwin. I am having more difficulty getting the alsa-lib software building on Darwin. >> >> I have not found anyone working on a Cocoa version of Spice Client. Can you let me know who these people might be? Thanks >> >> What do you think? >> > > Here's where I found the indication of an OSX port: http://lists.freedesktop.org/archives/spice-devel/2010-June/000583.html > > If you want to do an X11 build, then you do *not* want gtk-osx, which does a quartz build of Gtk+. As I'm sure you know, OSX does support X11, so your plan will work fine once you get past the audio issues. You might check MacPorts and Fink to see what they've done about audio. Yes, Darwin is Unix, but it's a Mach microkernel wrapped with NetBSD libraries, a very different design from Linux which is a gargantuan kernel that does everything. The main issue in your case is that sound is part of the kernel in Linux, but not in Darwin and that there is no standard sound API for Unix. I know that problem has been solved, because I've seen claims of having GStreamer working on OSX (not working particularly well, mind you, but working). > > In your place I would skip Phase One. I don't think that there's any benefit to that exercise. > > Regards, > John Ralls > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Gtk-osx-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users ____ |
From: John R. <jr...@ce...> - 2011-04-26 14:46:16
|
On Apr 26, 2011, at 5:28 AM, Cliff Sharp wrote: > Good suggestions. > > My plan is to get Spice Client working on OSX with as little changes as possible for Phase One. That means using Gtk and X11 as it is now in Spice Client since both of these already work on OSX. In other words, just to port it to Darwin. For this phase I would not Cocoa'ize it. I am ASSUMING since OSX is Unix (Darwin) under the covers this would not be that difficult - of course I don't know how true or not this is. > > Then Phase Two would be to replace/port Gtk/X11, sound, and whatever else to work on OSX. Using OpenGL, Core Audio, etc - Cocoa'ize it. > > Phase Three would be to then get Phase Two working on iOS. > > To date I have most of the Spice dependent libraries at least building under Darwin. I am having more difficulty getting the alsa-lib software building on Darwin. > > I have not found anyone working on a Cocoa version of Spice Client. Can you let me know who these people might be? Thanks > > What do you think? > Here's where I found the indication of an OSX port: http://lists.freedesktop.org/archives/spice-devel/2010-June/000583.html If you want to do an X11 build, then you do *not* want gtk-osx, which does a quartz build of Gtk+. As I'm sure you know, OSX does support X11, so your plan will work fine once you get past the audio issues. You might check MacPorts and Fink to see what they've done about audio. Yes, Darwin is Unix, but it's a Mach microkernel wrapped with NetBSD libraries, a very different design from Linux which is a gargantuan kernel that does everything. The main issue in your case is that sound is part of the kernel in Linux, but not in Darwin and that there is no standard sound API for Unix. I know that problem has been solved, because I've seen claims of having GStreamer working on OSX (not working particularly well, mind you, but working). In your place I would skip Phase One. I don't think that there's any benefit to that exercise. Regards, John Ralls |
From: Cliff S. <cs...@vb...> - 2011-04-26 12:28:52
|
Good suggestions. My plan is to get Spice Client working on OSX with as little changes as possible for Phase One. That means using Gtk and X11 as it is now in Spice Client since both of these already work on OSX. In other words, just to port it to Darwin. For this phase I would not Cocoa'ize it. I am ASSUMING since OSX is Unix (Darwin) under the covers this would not be that difficult - of course I don't know how true or not this is. Then Phase Two would be to replace/port Gtk/X11, sound, and whatever else to work on OSX. Using OpenGL, Core Audio, etc - Cocoa'ize it. Phase Three would be to then get Phase Two working on iOS. To date I have most of the Spice dependent libraries at least building under Darwin. I am having more difficulty getting the alsa-lib software building on Darwin. I have not found anyone working on a Cocoa version of Spice Client. Can you let me know who these people might be? Thanks What do you think? On Apr 26, 2011, at 12:08 AM, John Ralls wrote: > > On Apr 25, 2011, at 8:29 PM, Cliff Sharp wrote: > >> Spice is remote desktop software for Linux. >> It already is written to use X11 and GTK. >> >> I am porting it to OSX and iOS >> I thought that the gtk-osx project would give me a head start with Quartz but it would be better to use OpenGL regardless. >> > > Ah. Completely diffferent. > You're actually trying to build Spice-gtk (http://gitorious.org/spice-gtk/spice-gtk/trees/master/gtk), right? Looks doable except for audio. OSX and Linux have quite different sound architectures, so you'll have your work cut out getting that done. > > I don't think that you'll be successful getting Apple to let you put a Gtk+ app on the iTunes Store for your iPad. I saw some archived emails indicating some folks are working on a Cocoa implementation of Spice Client. That has a better chance of getting accepted (it's also likely to work better on both OSX and iOS), so perhaps you should join that effort. > > Regards, > John Ralls > > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Gtk-osx-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users |
From: John R. <jr...@ce...> - 2011-04-26 05:09:15
|
On Apr 25, 2011, at 8:29 PM, Cliff Sharp wrote: > Spice is remote desktop software for Linux. > It already is written to use X11 and GTK. > > I am porting it to OSX and iOS > I thought that the gtk-osx project would give me a head start with Quartz but it would be better to use OpenGL regardless. > Ah. Completely diffferent. You're actually trying to build Spice-gtk (http://gitorious.org/spice-gtk/spice-gtk/trees/master/gtk), right? Looks doable except for audio. OSX and Linux have quite different sound architectures, so you'll have your work cut out getting that done. I don't think that you'll be successful getting Apple to let you put a Gtk+ app on the iTunes Store for your iPad. I saw some archived emails indicating some folks are working on a Cocoa implementation of Spice Client. That has a better chance of getting accepted (it's also likely to work better on both OSX and iOS), so perhaps you should join that effort. Regards, John Ralls |
From: Cliff S. <cs...@vb...> - 2011-04-26 03:35:15
|
Spice is remote desktop software for Linux. It already is written to use X11 and GTK. I am porting it to OSX and iOS I thought that the gtk-osx project would give me a head start with Quartz but it would be better to use OpenGL regardless. Thanks for your reply Sent from my iPad On Apr 25, 2011, at 6:06 PM, John Ralls <jr...@ce...> wrote: > > On Apr 25, 2011, at 2:17 PM, Cliff Sharp wrote: > >> I am new to the gtk-osx project. >> I thinks it is a kool concept. >> >> I am attempting to create a moduleset for Spice. I am porting Spice to OS/X and then iOS. >> I would live to build a moduleset for Spice with all its dependencies. >> >> I have read the documentation but just have not been able to figure out how to create modulesets successfully. >> So I have been building the dependent libraries by hand in the jhbuild shell. >> >> I am stuck trying to build the dependent alsa-lib-1.0.24.1 on OS/X. >> >> Has anyone tried Spice and/or alsa-lib with gtk-osx??? >> > > It's unclear to me why you'd want to use Gtk with Spice (you are talking about the electronic circuit simulator, right?). Why not use MacSpice[1]? It's equally unclear to me what Alsa would have to do with Spice... unless you mean a different program. > > And while jhbuild can automate the build process, it doesn't do any porting work. So unless there's a CoreAudio backend to ALSA (seems unlikely), you'll either have to find a patched version of it somewhere or port it yourself -- which probably means writing a CoreAudio wrapper with the ALSA API. > > Regards, > John Ralls > > > > > > [1]http://mac.softpedia.com/get/Math-Scientific/MacSpice.shtml > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Gtk-osx-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users |
From: John R. <jr...@ce...> - 2011-04-25 23:06:55
|
On Apr 25, 2011, at 2:17 PM, Cliff Sharp wrote: > I am new to the gtk-osx project. > I thinks it is a kool concept. > > I am attempting to create a moduleset for Spice. I am porting Spice to OS/X and then iOS. > I would live to build a moduleset for Spice with all its dependencies. > > I have read the documentation but just have not been able to figure out how to create modulesets successfully. > So I have been building the dependent libraries by hand in the jhbuild shell. > > I am stuck trying to build the dependent alsa-lib-1.0.24.1 on OS/X. > > Has anyone tried Spice and/or alsa-lib with gtk-osx??? > It's unclear to me why you'd want to use Gtk with Spice (you are talking about the electronic circuit simulator, right?). Why not use MacSpice[1]? It's equally unclear to me what Alsa would have to do with Spice... unless you mean a different program. And while jhbuild can automate the build process, it doesn't do any porting work. So unless there's a CoreAudio backend to ALSA (seems unlikely), you'll either have to find a patched version of it somewhere or port it yourself -- which probably means writing a CoreAudio wrapper with the ALSA API. Regards, John Ralls [1]http://mac.softpedia.com/get/Math-Scientific/MacSpice.shtml |
From: Cliff S. <cs...@vb...> - 2011-04-25 21:17:18
|
I am new to the gtk-osx project. I thinks it is a kool concept. I am attempting to create a moduleset for Spice. I am porting Spice to OS/X and then iOS. I would live to build a moduleset for Spice with all its dependencies. I have read the documentation but just have not been able to figure out how to create modulesets successfully. So I have been building the dependent libraries by hand in the jhbuild shell. I am stuck trying to build the dependent alsa-lib-1.0.24.1 on OS/X. Has anyone tried Spice and/or alsa-lib with gtk-osx??? Thanks ____ |
From: Shawn B. <sha...@ho...> - 2011-04-25 18:27:55
|
I whole heatedly agree with John. He speaks true words of wisdom. I wish I had (listened to) that advice 3 years ago, when I started down GTk for the expressed reason of cross compatibility. If you are starting from scratch, don't start with GTK. As a novice, I can attest to that. It is true, just cause you can do object oriented programming in C does not mean you should. In fact I would not even call it a C based interface it really isn't for all practical matter (personally I think it's worse for it). I don't know about other cross platform tools, but I would seriously consider the audience, and if there is no need to be cross platform, there are many advantages of going native. I have started down that path myself, trying to separate enough of the logic (in C using just libc et al, which is very portable), to have minimum interface components, that if needed, can be re-written Native to the OS interface. You can also always do an html via web, but I never see those as serious applications. the whole get_object* set_object* stuff just does not work. I ended up writing a lot of bloat trying to follow the mantra only to realize having a structure with members is ultimately much easier to code than calling a bunch of get/set_Object*. > From: jr...@ce... > Date: Sun, 24 Apr 2011 09:00:24 -0700 > To: gtk...@li... > Subject: Re: [Gtk-osx-users] Question about programs portability > > > On Apr 24, 2011, at 8:10 AM, Tommaso Ricci wrote: > > > I have a question about gtk, i'm a new programmer and i'm in trouble with the gtk portability.. > > My question is: to run my gtk compiled application written in c my computer must have gtk installed??? For example if i give my mac-compiled app to a friend that as the same mac will he be able to run that? > > > > Well, on OSX you include Gtk (and all of the other libraries that your application requires) in the application bundle. MS Windows users will need to install those libraries, so for that platform you'll use an installer program. On Linux the user will have to install Gtk+ and the other dependencies via the package manager if she doesn't already have them installed. This is equally true of all cross-platform frameworks. > > As I've written in the wiki, though, Gtk+ is not a good choice for new work if cross-platform portability is important to you. Although much improved over the last two years, Gtk+ remains primarily a Unix toolkit that happens (through a lot of hard work by nowhere near enough people) to compile and run on OSX and MS Windows. Qt and wxWidgets, which are designed and built with the primary goal of being cross-platform, are much better toolkits. > > Since you're new to programming, I suggest that you avoid Gtk+ for another reason: It's weird. The underlying premise is that it's possible, and therefore desirable, to write object-oriented code in pure C. Well, it is possible, but it's a bad idea, and you will learn all manner of very bad habits from taking that path. Instead, learn Python or Java, learn how to decompose problems into objects, and learn how to separate your application into models, views, and controllers. After you've practiced that for a few years you can come back to C/C++/ObjectiveC if you want to, and you'll be on much firmer ground for learning to use them well. > > If you want to continue this conversation, you'll need to join the list. The URL is tacked on at the bottom of each message after Sourceforge's ad. > > Regards, > John Ralls > > > ------------------------------------------------------------------------------ > Fulfilling the Lean Software Promise > Lean software platforms are now widely adopted and the benefits have been > demonstrated beyond question. Learn why your peers are replacing JEE > containers with lightweight application servers - and what you can gain > from the move. http://p.sf.net/sfu/vmware-sfemails > _______________________________________________ > Gtk-osx-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users |
From: John R. <jr...@ce...> - 2011-04-24 16:00:37
|
On Apr 24, 2011, at 8:10 AM, Tommaso Ricci wrote: > I have a question about gtk, i'm a new programmer and i'm in trouble with the gtk portability.. > My question is: to run my gtk compiled application written in c my computer must have gtk installed??? For example if i give my mac-compiled app to a friend that as the same mac will he be able to run that? > Well, on OSX you include Gtk (and all of the other libraries that your application requires) in the application bundle. MS Windows users will need to install those libraries, so for that platform you'll use an installer program. On Linux the user will have to install Gtk+ and the other dependencies via the package manager if she doesn't already have them installed. This is equally true of all cross-platform frameworks. As I've written in the wiki, though, Gtk+ is not a good choice for new work if cross-platform portability is important to you. Although much improved over the last two years, Gtk+ remains primarily a Unix toolkit that happens (through a lot of hard work by nowhere near enough people) to compile and run on OSX and MS Windows. Qt and wxWidgets, which are designed and built with the primary goal of being cross-platform, are much better toolkits. Since you're new to programming, I suggest that you avoid Gtk+ for another reason: It's weird. The underlying premise is that it's possible, and therefore desirable, to write object-oriented code in pure C. Well, it is possible, but it's a bad idea, and you will learn all manner of very bad habits from taking that path. Instead, learn Python or Java, learn how to decompose problems into objects, and learn how to separate your application into models, views, and controllers. After you've practiced that for a few years you can come back to C/C++/ObjectiveC if you want to, and you'll be on much firmer ground for learning to use them well. If you want to continue this conversation, you'll need to join the list. The URL is tacked on at the bottom of each message after Sourceforge's ad. Regards, John Ralls |
From: Tommaso R. <zor...@gm...> - 2011-04-24 15:10:45
|
I have a question about gtk, i'm a new programmer and i'm in trouble with the gtk portability.. My question is: to run my gtk compiled application written in c my computer must have gtk installed??? For example if i give my mac-compiled app to a friend that as the same mac will he be able to run that? Thank you |
From: Tim C. <ht....@gm...> - 2011-04-19 18:57:21
|
> > The problem is that gimp is firing up an event loop, which is waiting for gimp to get focus. When you launch it from the command line, the terminal keeps focus, so gimp hangs until you switch focus to it. Click in the splash screen or command-tab to select gimp and it should finish up and display its palettes and menu. > > 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...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users Yes, switching the focus fix the hang. After fighting with macports, fink and jhbuild for almost a week, I can finally continue my GIMP hacking on Mac! Thank you very much for the time and efforts! best regards, Tim -------------------------------------------------------------------- http://ht-timchen.org |
From: John R. <jr...@ce...> - 2011-04-19 18:50:24
|
On Apr 19, 2011, at 11:25 AM, John Ralls wrote: > > On Apr 19, 2011, at 2:28 AM, Tim Chen wrote: > >> 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? > > The autoregen failure was from a typo in the moduleset, fixed and pushed, thanks. > > The mmx problem is because gimp's configure has code which determines that you have a 64-bit machine and ignores the -arch i386 CFLAG, so it sets up for x86_64 assembly instead of x86 assembly; gcc sensibly declines to do that. You can override configure by adding the line > > append_autogenargs("gimp", "--host=i686-darwin10.5.0 --target=i686-darwin10.5.0") > > to your .jhbuildrc-custom. > > I get the hang, too, so I'm building a debug version so that I can see what's hanging it up. I'll get back to you on that once I've figured out the problem. > > (By the way, don't get tempted to try a 64-bit build; they're still using ige-mac-integration. I'll file a bug with them about that.) The problem is that gimp is firing up an event loop, which is waiting for gimp to get focus. When you launch it from the command line, the terminal keeps focus, so gimp hangs until you switch focus to it. Click in the splash screen or command-tab to select gimp and it should finish up and display its palettes and menu. Regards, John Ralls |
From: John R. <jr...@ce...> - 2011-04-19 18:25:16
|
On Apr 19, 2011, at 2:28 AM, Tim Chen wrote: > 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? The autoregen failure was from a typo in the moduleset, fixed and pushed, thanks. The mmx problem is because gimp's configure has code which determines that you have a 64-bit machine and ignores the -arch i386 CFLAG, so it sets up for x86_64 assembly instead of x86 assembly; gcc sensibly declines to do that. You can override configure by adding the line append_autogenargs("gimp", "--host=i686-darwin10.5.0 --target=i686-darwin10.5.0") to your .jhbuildrc-custom. I get the hang, too, so I'm building a debug version so that I can see what's hanging it up. I'll get back to you on that once I've figured out the problem. (By the way, don't get tempted to try a 64-bit build; they're still using ige-mac-integration. I'll file a bug with them about that.) Regards, John Ralls |
From: Tim C. <ht....@gm...> - 2011-04-19 09:28:53
|
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...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users |
From: John R. <jr...@ce...> - 2011-04-19 05:04:25
|
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 |
From: Tim C. <ht....@gm...> - 2011-04-19 04:08:34
|
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? thanks for your reply in advance. -Tim ------------------------- http://ht-timchen.org On Apr 19, 2011, at 4:26 AM, John Ralls wrote: > > On Apr 18, 2011, at 11:16 AM, Tim Chen wrote: > >> Hi, >> >> I am trying to build gimp on my 2011 MacBook Pro (64 bit) via jhbuild. >> >> I basically follow the instruction on http://sourceforge.net/apps/trac/gtk-osx/wiki/Build >> >> and I update the .jhbuildrc-custom file with >> >> setup_sdk(target="10.6", sdk_version="10.6", architectures=["i386"]) >> build_policy="updated-deps" >> os.environ["ARCHFLAGS"] = "-arch x86_64 -arch i386" >> moduleset = "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules" >> >> everything goes well with >> >> $ jhbuild bootstrap >> $ jhbuild build meta-gtk-osx-bootstrap >> $ jhbuild build meta-gtk-osx-core >> >> However, when I am trying to build gimp with $ jhbuild build gimp >> >> it complains about glib while configuring GEGL : >> >> checking for GLIB - version >= 2.22.0... no >> *** Could not run GLIB test program, checking why... >> *** The test program failed to compile or link. See the file config.log for the >> *** exact error that occured. This usually means GLIB is incorrectly installed. >> >> Is there anything I missed? > > Please post the error from config.log. > > The current Glib in stable is 2.27, and I just built gegl in my tree, so something's messed up in yours. > > 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...@li... > https://lists.sourceforge.net/lists/listinfo/gtk-osx-users |
From: John R. <jr...@ce...> - 2011-04-18 20:26:14
|
On Apr 18, 2011, at 11:16 AM, Tim Chen wrote: > Hi, > > I am trying to build gimp on my 2011 MacBook Pro (64 bit) via jhbuild. > > I basically follow the instruction on http://sourceforge.net/apps/trac/gtk-osx/wiki/Build > > and I update the .jhbuildrc-custom file with > > setup_sdk(target="10.6", sdk_version="10.6", architectures=["i386"]) > build_policy="updated-deps" > os.environ["ARCHFLAGS"] = "-arch x86_64 -arch i386" > moduleset = "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules" > > everything goes well with > > $ jhbuild bootstrap > $ jhbuild build meta-gtk-osx-bootstrap > $ jhbuild build meta-gtk-osx-core > > However, when I am trying to build gimp with $ jhbuild build gimp > > it complains about glib while configuring GEGL : > > checking for GLIB - version >= 2.22.0... no > *** Could not run GLIB test program, checking why... > *** The test program failed to compile or link. See the file config.log for the > *** exact error that occured. This usually means GLIB is incorrectly installed. > > Is there anything I missed? Please post the error from config.log. The current Glib in stable is 2.27, and I just built gegl in my tree, so something's messed up in yours. Regards, John Ralls |
From: Tim C. <ht....@gm...> - 2011-04-18 18:17:01
|
Hi, I am trying to build gimp on my 2011 MacBook Pro (64 bit) via jhbuild. I basically follow the instruction on http://sourceforge.net/apps/trac/gtk-osx/wiki/Build and I update the .jhbuildrc-custom file with setup_sdk(target="10.6", sdk_version="10.6", architectures=["i386"]) build_policy="updated-deps" os.environ["ARCHFLAGS"] = "-arch x86_64 -arch i386" moduleset = "http://github.com/jralls/gtk-osx-build/raw/master/modulesets-stable/gtk-osx.modules" everything goes well with $ jhbuild bootstrap $ jhbuild build meta-gtk-osx-bootstrap $ jhbuild build meta-gtk-osx-core However, when I am trying to build gimp with $ jhbuild build gimp it complains about glib while configuring GEGL : checking for GLIB - version >= 2.22.0... no *** Could not run GLIB test program, checking why... *** The test program failed to compile or link. See the file config.log for the *** exact error that occured. This usually means GLIB is incorrectly installed. Is there anything I missed? thanks for your help, -Tim |
From: Chap H. <cl...@po...> - 2011-04-17 23:50:26
|
Okay -- I encountered the same error at the same place on a new user account. Then I created a new user on my Mac Mini (Intel) which does *not* have Xcode 4. (It has Xcode 3.latest.) I was able to get through the installation process there. Unfortunately the mini is headless and I operate the GUI with screen sharing, so it's not ideal for testing GTK. Better than nothing, though :) If anyone has some ideas from this about how my laptop's environment might be screwed up, I'd be grateful. Thanks, Chap |
From: Chap H. <cl...@po...> - 2011-04-17 20:04:07
|
On Apr 17, 2011, at 2:25 PM, John Ralls wrote: > > No, but you've messed something up. "dnl" introduces comments in the m4 macro language... which implies that whatever autoreconf called, it wasn't the right m4. But it's strange that you got all of the way to Gtk+ before the problem showed up. Did you start fresh or were you rebuilding an already-existing tree? I think the answer is, I was starting fresh. Don't know much about "trees." Perhaps I should create a virgin Mac OS X user and retry the process there. My concern is, will the installation be available to all users, or just that user? Thanks, Chap |
From: John R. <jr...@ce...> - 2011-04-17 19:26:02
|
On Apr 17, 2011, at 9:01 AM, Chap Harrison wrote: > Hi, > > I encountered this error during the jhbuild build meta-gtk-osx-core step of the instructions at https://sourceforge.net/apps/trac/gtk-osx/wiki/Build. I'm running 10.6.7 and have Xcode 4.0.1 (and I ran export ARCHFLAGS="-arch x86_64 -arch i386"). Does anyone know how to fix this? > > Thanks, > Chap > > > *** Configuring gtk+ *** [10/12] > autoreconf -fis && ./configure --prefix /Users/chap/gtk/inst --libdir '/Users/chap/gtk/inst/lib' --with-gdktarget=quartz --disable-static > libtoolize: putting auxiliary files in `.'. > libtoolize: linking file `./ltmain.sh' > libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. > libtoolize: linking file `m4/libtool.m4' > libtoolize: linking file `m4/ltoptions.m4' > libtoolize: linking file `m4/ltsugar.m4' > libtoolize: linking file `m4/ltversion.m4' > libtoolize: linking file `m4/lt~obsolete.m4' > configure.in:150: error: possibly undefined macro: dnl > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /Users/chap/gtk/inst/bin/autoconf failed with exit status: 1 > *** Error during phase configure of gtk+: ########## Error running autoreconf -fis && ./configure --prefix /Users/chap/gtk/inst --libdir '/Users/chap/gtk/inst/lib' --with-gdktarget=quartz --disable-static *** tk-...@li... No, but you've messed something up. "dnl" introduces comments in the m4 macro language... which implies that whatever autoreconf called, it wasn't the right m4. But it's strange that you got all of the way to Gtk+ before the problem showed up. Did you start fresh or were you rebuilding an already-existing tree? Regards, John Ralls |
From: Chap H. <cl...@po...> - 2011-04-17 16:15:08
|
Hi, I encountered this error during the jhbuild build meta-gtk-osx-core step of the instructions at https://sourceforge.net/apps/trac/gtk-osx/wiki/Build. I'm running 10.6.7 and have Xcode 4.0.1 (and I ran export ARCHFLAGS="-arch x86_64 -arch i386"). Does anyone know how to fix this? Thanks, Chap *** Configuring gtk+ *** [10/12] autoreconf -fis && ./configure --prefix /Users/chap/gtk/inst --libdir '/Users/chap/gtk/inst/lib' --with-gdktarget=quartz --disable-static libtoolize: putting auxiliary files in `.'. libtoolize: linking file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: linking file `m4/libtool.m4' libtoolize: linking file `m4/ltoptions.m4' libtoolize: linking file `m4/ltsugar.m4' libtoolize: linking file `m4/ltversion.m4' libtoolize: linking file `m4/lt~obsolete.m4' configure.in:150: error: possibly undefined macro: dnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. autoreconf: /Users/chap/gtk/inst/bin/autoconf failed with exit status: 1 *** Error during phase configure of gtk+: ########## Error running autoreconf -fis && ./configure --prefix /Users/chap/gtk/inst --libdir '/Users/chap/gtk/inst/lib' --with-gdktarget=quartz --disable-static *** [10/12] [1] Rerun phase configure [2] Ignore error and continue to build [3] Give up on module [4] Start shell [5] Reload configuration [6] Go to phase "wipe directory and start over" [7] Go to phase "clean" [8] Go to phase "distclean" |
From: John R. <jr...@ce...> - 2011-04-15 02:34:44
|
On Apr 14, 2011, at 1:29 PM, Pascal wrote: > Hello, thanks for making tremendous GTK-OSX! > > Just to report that the install is nice. > I have one small problem with access to libtiff on http://download.osgeo.org/, they gave me an other URL: > http://download2.osgeo.org/ > > I've also install GTK for Ada from Adacore: > http://libre.adacore.com/libre/tools/GtkAda/ > > It was installed perfectly. > I've just had to remove -arch x86_64 from CFLAGS because GNAT don't understand it. > I've done it by hand with Terminal. Is there some configuration file to modify? > Yes, and instructions are in the stock .jhbuildrc-custom that was installed by gtk-osx-build-setup.sh. Thanks for the heads-up about libtiff. But they both seem to be working at the moment, and there's no way to tell jhbuild about fallback download sites. Regards, John Ralls |
From: Pascal <p....@or...> - 2011-04-14 20:29:16
|
Hello, thanks for making tremendous GTK-OSX! Just to report that the install is nice. I have one small problem with access to libtiff on http://download.osgeo.org/, they gave me an other URL: http://download2.osgeo.org/ I've also install GTK for Ada from Adacore: http://libre.adacore.com/libre/tools/GtkAda/ It was installed perfectly. I've just had to remove -arch x86_64 from CFLAGS because GNAT don't understand it. I've done it by hand with Terminal. Is there some configuration file to modify? Regards, Pascal. http://blady.pagesperso-orange.fr |
From: John R. <jr...@ce...> - 2011-04-12 21:51:30
|
On Apr 12, 2011, at 10:21 AM, Mikkel Kruse Johnsen wrote: > I can see that you are not much for C#, thats fine. > > My patch is no more a no-op than other gtk_*_new, and many don't do anything, like GtkEntry: > -- > GtkWidget* > gtk_entry_new (void) > { > return g_object_new (GTK_TYPE_ENTRY, NULL); > } > -- > The point is to make it easier and more consistent. And also easier to wrap. > > Yes i realize that my problem is with mono, actually with all virtual languages. I can see the people using Python have the same problems, that "NSApplication terminate" is calling exit. So they don't have time to cleanup. Sorry if I wasted your time. > Has nothing to do with C# in particular. There are thousands of computer languages, and dozens of independently maintained wrappers of Gtk. That's too much for a one-person-part-time project to support. Gnome officially supports C++ and Python, so that's what I support for wrappers. The term for your patch is "syntactic sugar". It accomplishes nothing besides saving some typing, and makes absolutely no difference for writing a wrapper... but it might make a difference for gobject-introspection, so I might do it for that. Mono is another matter entirely. For one thing, it's not a "virtual language", it's a runtime framework (that can run several languages, of which C# is the most well known). It has it's own event loop which integrates with the OS's event loop. Gtk also has its own event loop (provided by GLib) which integrates with the OS's event loop -- and probably does so differently from the way mono does. Mixing the two is asking for trouble. You might be able to fix your crash by getting your Mono layer to also handle either NSApplicationShouldTerminate or NSApplicationWillTerminate and do whatever cleanup it needs to do. You'll have to write some Cocoa (objective-c) code to do it, but it's not difficult. You can use the code in GtkApplicationNotify.c as a template. The hard part will be making sure that you don't have a race condition between the two event loops. I don't think that has anything to do with Python code crashing at exit (if it does: test-integration.py doesn't, but it doesn't do much of anything, either). Python doesn't have its own event loop. Regards, John Ralls |