RE: Gtk-OSX Frameworks (was: Why are developers...)



Re-build using jhbuild today:

1) Take new OS X Snow Leopard out of box (Nice!)
2) Apply all updates and installed xCode
3) Download and install latest version of git from http://code.google.com/p/git-osx-installer
4) open terminal:
5) type   "sh gtk-osx-build-setup.sh" (let run)
6) when done; type "export PATH=$PATH:/Users/shawn/.local/bin"
6.1) obviously use your own name instead of shawn (me :) )

7) type "jhbuild bootstrap" (12/12 completed no problem)
8) type  "jhbuild build meta-gtk-osx-bootstrap" (13/13 completed with no problem)

9) type: "jhbuild build meta-gtk-osx-core"
9.1) ERROR: no libiconv but header used
9.2) Open a new shell
9.3) download the latest version of libiconv from http://www.gnu.org/software/libiconv
9.4) Unpack the files into source tree (for me : /Users/shawn/gtk/source );
9.5) in new shell type "jhbuild shell"; cd into the source
9.6) type "./configure --prefix=/Users/shawn/gtk/inst", which will configure it to go into the same place you GTK builds will go
9.7) type "make; make install"
9.8) return to 9.1 and simply re-run the configuration stage (I believe choice # 7)

10) ige-mac-integration warns about nested and implicit decelerations .... 
10.1) start shell by choosing 4
10.2) Edit the src/Makefile.am and remove $(WARN_CFLAGS)
10.3) Re-run stage configuration (Option # 7)
10.4) 11/11 completed no problems

11) type "jhbuild build libglade" (completed no problems)

Optional (I need MySQL):
12) download source form mysql site and unpack in source directory
13) type "configure --prefix=/User/shawn/gtk/inst"
14) type "make; make install" (have a cig)

I am able to fully compile my application with no problems. However I am running into a serious issue, and I don't know if it is my crappy programming or if this is a real issue on the 64bit, all of a sudden there are tons of execution errors, for example,


<--in isidisplay.c -->

GtkWidget *
 isi_display_get_widget(IsiDisplay *self, const gchar* object)
{

     /* Sanity Check */
    g_return_val_if_fail(self != NULL, FALSE);
    g_return_val_if_fail(self->priv != NULL, FALSE);
    g_return_val_if_fail(self->priv->dispose_has_run != TRUE, FALSE);
 
    /* Get teh XML File and load XML Object */
    return glade_xml_get_widget (self->priv->xml, object);

return NULL;}

<-- in isiapp.c-->

gboolean
 isi_app_initialize_default_interface(IsiApp *self){

    /* Local vars */
    GdkWindow *g_window = NULL;

   
    GtkWindow *main_window        = NULL; /* Temp widget pointer for search otpions setup */


........

    main_window = isi_display_get_widget(self->display,"orderdesk");
    g_object_get((GObject*)main_window,"window",&g_window,NULL);

 .......

}


crud out with the following error in gdb:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000002019230
0x0000000100c343b0 in g_object_get (_object=0x2019230, first_property_name=0x1000973c5 "window") at gobject.c:1630
1630      g_return_if_fail (G_IS_OBJECT (object));
(gdb) bt
#0  0x0000000100c343b0 in g_object_get (_object=0x2019230, first_property_name=0x1000973c5 "window") at gobject.c:1630
#1  0x000000010001b7ff in isi_app_initialize_default_interface (self=0x10201a000) at isiapp.c:6209
#2  0x000000010000ae0a in main (argc=1, argv=0x7fff5fbfec08) at isimain.c:53
(gdb) bt
#0  0x0000000100c343b0 in g_object_get (_object=0x2019230, first_property_name=0x1000973c5 "window") at gobject.c:1630
#1  0x000000010001b7ff in isi_app_initialize_default_interface (self=0x10201a000) at isiapp.c:6209
#2  0x000000010000ae0a in main (argc=1, argv=0x7fff5fbfec08) at isimain.c:53



{scratching head dumbfounded} I comment out the above code and tried again, getting an error same thing but in a completely different area:


 gboolean
 isi_app_setup_menu(IsiApp *self)
{

    /* Local Variables */
    GtkWidget *menu = NULL;
    GtkWidget **widget = NULL;
    IsiCategory* c;

    guint num_rows;
    guint *p_index;             /* Index of top level cats */
    guint *c_index;            /* Index of child level cats */
    guint i,j,k;            /* Loop variables */


    /* Sanity Check */
    g_return_val_if_fail(self != NULL, FALSE);
    g_return_val_if_fail(self->priv != NULL, FALSE);
    g_return_val_if_fail(self->priv->dispose_has_run != TRUE, FALSE);


    /* If valid rows */
    if(self->priv->user_perms != NULL && self->priv->user_perms->rows != NULL){

        /* Get number of rows */
        guint num_rows = g_list_length(self->priv->user_perms->rows);

 ......

     }

/* By default return FALSE to permission checks */
return FALSE;
}


gdb output:

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000018639f8
0x000000010001a3c6 in isi_app_setup_menu (self=0x10201b000) at isiapp.c:2583
2583        if(self->priv->user_perms != NULL && self->priv->user_perms->rows != NULL){
(gdb) bt
#0  0x000000010001a3c6 in isi_app_setup_menu (self=0x10201b000) at isiapp.c:2583
#1  0x000000010001b816 in isi_app_initialize_default_interface (self=0x10201b000) at isiapp.c:6204
#2  0x000000010000ae0a in main (argc=1, argv=0x7fff5fbfec08) at isimain.c:53


I am going to try an do what Jralls suggest and perhaps re-build with both -g and see if I can not trace this better, also try to build the library as 32bit and see what happens than. But this application has been running great using this technique on the 32 bit interface with no problems what so ever! I can't figure out why I have all kinds of bad memory references.

I just noticed the there seems to be 32bit memory addresses intermingled with 64bit? IE in the above output self is 32bit but the address lookup is 64bit ?? Is that right? Same with the code??

Do I need to post this to gtk-app or is this something wrong in the backend (perhaps I am compiling with wrong options ??)

HELP :S :'S :"S :''''S




i'm EMAILING FOR THE GREATER GOOD
Join me



Subject: Re: Gtk-OSX Frameworks (was: Why are developers...)
From: jacob juvul com
Date: Tue, 10 Nov 2009 18:20:26 +0100
CC: gtk-devel-list gnome org
To: shashaness hotmail com

On Nov 10, 2009, at 4:46 PM, Shawn Bakhtiar wrote:

For building an application... I couldn't agree more, about the framework vs. jhbuild and autotools. You definitely want the latter. I like XCode's editor. when looking at source code (the colors man the colors). It also has a lot of nice features such as collapsible sections, an intuitive way of knowing if you {} are correct, as well as a jump to function feature that list all functions in the current file in a drop down menu. However, you can use the editor, and build in shell (jhbuild shell). In any case, gdb is a much better debugger to boot.

But yeah.. just try to build mysql with it, or even use it in a build. Good luck!!

Also using the ige-mac-bundler, users now simple drag and drop the latest package (application) to their application folder, and they are done, especially if you adhere to the XDG file system. 

I don't know what all the complaint is about... I have been using the jhbuild scripts with little to no problems. I have had a few dependency issues but nothing that can not be figured out with a little reading of the script itself and attention to what I am doing. In any case, anything that is missing, simple download to source directory, and build inside the jhbuild shell, your done!

Like I said, I'm not too good with the back-end stuff, but it looks like I will be getting my own Snow Leopard today, I can re-run the jhbuild stuff from scratch, and see if I can't get a framework out. Would this help?

That  would be great!
I've been trying to build it on Snow Leopard, butI i'm stuck now with 
jhbuild meta-gtk-osx-core failing to  build ige-mac-integration:

*** Building ige-mac-integration *** [10/11]
make  
make  all-recursive
Making all in src
if /bin/sh ../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I..  -I.. -Wall -Wunused -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -std=c99 -Wno-sign-compare -Wno-pointer-sign -Werror -I/Users/dacobi/gtk/inst/include -I/Users/dacobi/gtk/inst/include/gtk-2.0 -I/Users/dacobi/gtk/inst/lib/gtk-2.0/include -I/Users/dacobi/gtk/inst/include/atk-1.0 -I/Users/dacobi/gtk/inst/include/cairo -I/Users/dacobi/gtk/inst/include/pango-1.0 -I/Users/dacobi/gtk/inst/include/glib-2.0 -I/Users/dacobi/gtk/inst/lib/glib-2.0/include -I/Users/dacobi/gtk/inst/include/pixman-1 -I/Users/dacobi/gtk/inst/include/freetype2 -I/Users/dacobi/gtk/inst/include/libpng12   -xobjective-c -g -O2 -MT libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF ".deps/libigemacintegration_la-ige-mac-menu.Tpo" -c -o libigemacintegration_la-ige-mac-menu.lo `test -f 'ige-mac-menu.c' || echo './'`ige-mac-menu.c; \
then mv -f ".deps/libigemacintegration_la-ige-mac-menu.Tpo" ".deps/libigemacintegration_la-ige-mac-menu.Plo"; else rm -f ".deps/libigemacintegration_la-ige-mac-menu.Tpo"; exit 1; fi
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I. -I.. -I.. -Wall -Wunused -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -std=c99 -Wno-sign-compare -Wno-pointer-sign -Werror -I/Users/dacobi/gtk/inst/include -I/Users/dacobi/gtk/inst/include/gtk-2.0 -I/Users/dacobi/gtk/inst/lib/gtk-2.0/include -I/Users/dacobi/gtk/inst/include/atk-1.0 -I/Users/dacobi/gtk/inst/include/cairo -I/Users/dacobi/gtk/inst/include/pango-1.0 -I/Users/dacobi/gtk/inst/include/glib-2.0 -I/Users/dacobi/gtk/inst/lib/glib-2.0/include -I/Users/dacobi/gtk/inst/include/pixman-1 -I/Users/dacobi/gtk/inst/include/freetype2 -I/Users/dacobi/gtk/inst/include/libpng12 -xobjective-c -g -O2 -MT libigemacintegration_la-ige-mac-menu.lo -MD -MP -MF .deps/libigemacintegration_la-ige-mac-menu.Tpo -c ige-mac-menu.c  -fno-common -DPIC -o .libs/libigemacintegration_la-ige-mac-menu.o
cc1obj: warnings being treated as errors
ige-mac-menu.c: In function ‘menu_flash_off_cb’:
ige-mac-menu.c:77: warning: implicit declaration of function ‘FlashMenuBar’
ige-mac-menu.c:77: warning: nested extern declaration of ‘FlashMenuBar’
ige-mac-menu.c: In function ‘carbon_menu_free’:
ige-mac-menu.c:139: warning: implicit declaration of function ‘DisposeMenu’
ige-mac-menu.c:139: warning: nested extern declaration of ‘DisposeMenu’
ige-mac-menu.c: In function ‘carbon_menu_item_free’:
ige-mac-menu.c:182: warning: implicit declaration of function ‘DeleteMenuItem’
ige-mac-menu.c:182: warning: nested extern declaration of ‘DeleteMenuItem’
ige-mac-menu.c: In function ‘carbon_menu_item_get_checked’:
ige-mac-menu.c:294: warning: implicit declaration of function ‘GetMenuItemProperty’
ige-mac-menu.c:294: warning: nested extern declaration of ‘GetMenuItemProperty’
ige-mac-menu.c: In function ‘carbon_menu_item_update_state’:
ige-mac-menu.c:337: warning: implicit declaration of function ‘ChangeMenuItemAttributes’
ige-mac-menu.c:337: warning: nested extern declaration of ‘ChangeMenuItemAttributes’
ige-mac-menu.c: In function ‘carbon_menu_item_update_active’:
ige-mac-menu.c:347: warning: implicit declaration of function ‘CheckMenuItem’
ige-mac-menu.c:347: warning: nested extern declaration of ‘CheckMenuItem’
ige-mac-menu.c: In function ‘carbon_menu_item_update_submenu’:
ige-mac-menu.c:361: warning: implicit declaration of function ‘SetMenuItemHierarchicalMenu’
ige-mac-menu.c:361: warning: nested extern declaration of ‘SetMenuItemHierarchicalMenu’
ige-mac-menu.c:367: warning: implicit declaration of function ‘CreateNewMenu’
ige-mac-menu.c:367: warning: nested extern declaration of ‘CreateNewMenu’
ige-mac-menu.c:373: warning: implicit declaration of function ‘SetMenuTitleWithCFString’
ige-mac-menu.c:373: warning: nested extern declaration of ‘SetMenuTitleWithCFString’
ige-mac-menu.c: In function ‘carbon_menu_item_update_label’:
ige-mac-menu.c:394: warning: implicit declaration of function ‘SetMenuItemTextWithCFString’
ige-mac-menu.c:394: warning: nested extern declaration of ‘SetMenuItemTextWithCFString’
ige-mac-menu.c: In function ‘carbon_menu_item_update_accelerator’:
ige-mac-menu.c:417: warning: implicit declaration of function ‘SetMenuItemModifiers’
ige-mac-menu.c:417: warning: nested extern declaration of ‘SetMenuItemModifiers’
ige-mac-menu.c:423: warning: implicit declaration of function ‘SetMenuItemCommandKey’
ige-mac-menu.c:423: warning: nested extern declaration of ‘SetMenuItemCommandKey’
ige-mac-menu.c: In function ‘carbon_menu_item_create’:
ige-mac-menu.c:588: warning: implicit declaration of function ‘InsertMenuItemTextWithCFString’
ige-mac-menu.c:588: warning: nested extern declaration of ‘InsertMenuItemTextWithCFString’
ige-mac-menu.c:592: warning: implicit declaration of function ‘SetMenuItemProperty’
ige-mac-menu.c:592: warning: nested extern declaration of ‘SetMenuItemProperty’
ige-mac-menu.c: In function ‘nsevent_handle_menu_key’:
ige-mac-menu.c:724: warning: implicit declaration of function ‘IsMenuKeyEvent’
ige-mac-menu.c:724: warning: nested extern declaration of ‘IsMenuKeyEvent’
ige-mac-menu.c:727: warning: implicit declaration of function ‘GetMenuItemCommandID’
ige-mac-menu.c:727: warning: nested extern declaration of ‘GetMenuItemCommandID’
ige-mac-menu.c:740: warning: implicit declaration of function ‘GetMenuID’
ige-mac-menu.c:740: warning: nested extern declaration of ‘GetMenuID’
ige-mac-menu.c:742: warning: implicit declaration of function ‘GetMenuEventTarget’
ige-mac-menu.c:742: warning: nested extern declaration of ‘GetMenuEventTarget’
ige-mac-menu.c:742: warning: passing argument 2 of ‘SendEventToEventTarget’ makes pointer from integer without a cast
ige-mac-menu.c: In function ‘sync_menu_shell’:
ige-mac-menu.c:921: warning: implicit declaration of function ‘GetMenuAttributes’
ige-mac-menu.c:921: warning: nested extern declaration of ‘GetMenuAttributes’
ige-mac-menu.c:927: warning: implicit declaration of function ‘ChangeMenuAttributes’
ige-mac-menu.c:927: warning: nested extern declaration of ‘ChangeMenuAttributes’
ige-mac-menu.c: In function ‘parent_set_emission_hook_remove’:
ige-mac-menu.c:988: warning: implicit declaration of function ‘ClearMenuBar’
ige-mac-menu.c:988: warning: nested extern declaration of ‘ClearMenuBar’
ige-mac-menu.c:989: warning: implicit declaration of function ‘DeleteMenu’
ige-mac-menu.c:989: warning: nested extern declaration of ‘DeleteMenu’
ige-mac-menu.c: In function ‘window_focus’:
ige-mac-menu.c:1001: warning: implicit declaration of function ‘SetRootMenu’
ige-mac-menu.c:1001: warning: nested extern declaration of ‘SetRootMenu’
ige-mac-menu.c: In function ‘ige_mac_menu_set_quit_menu_item’:
ige-mac-menu.c:1068: warning: implicit declaration of function ‘GetIndMenuItemWithCommandID’
ige-mac-menu.c:1068: warning: nested extern declaration of ‘GetIndMenuItemWithCommandID’
ige-mac-menu.c:1071: warning: implicit declaration of function ‘SetMenuItemCommandID’
ige-mac-menu.c:1071: warning: nested extern declaration of ‘SetMenuItemCommandID’
make[2]: *** [libigemacintegration_la-ige-mac-menu.lo] Error 1
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
*** Error during phase build of ige-mac-integration: ########## Error running make   *** [10/11]

Anyone?

/Jacob



i'm EMAILING FOR THE GREATER GOOD
Join me


> From: jralls ceridwen us
> Subject: Re: Gtk-OSX Frameworks (was: Why are developers...)
> Date: Tue, 10 Nov 2009 07:10:09 -0800
> To: gtk-devel-list gnome org
> 
> 
> On Nov 10, 2009, at 4:16 AM, Paul Davis wrote:
> 
> > On Mon, Nov 9, 2009 at 1:10 PM, Jack Skellington <dacobi gmail com> 
> > wrote:
> >
> >> Also if a native Gtk+ OS X framework were available people who are
> >> maintaining Gtk+ apps would have the option to extend their user base
> >> to OS X quite quickly.
> >
> > All it requires to use it is to build the GTK stack yourself using the
> > instructions provided (i wish the instructions had not been moved away
> > from gnome.org, but they are still easy to find). I should put "all"
> > in quotes because if you choose to follow bleeding edge GTK then you
> > will find that maintaining your built version can be quite a lot of
> > work in the face of breakages and changes in many different parts of
> > the stack. This is not true (or at least, it is MUCH less true) if you
> > use a recent release version (there are instructions on how to do that
> > included in the gtk osx build info).
> >
> > I do not believe that using a pre-built GTK OS X framework is
> > desirable for users or developers. Include GTK as part of your app
> > bundle. Its not hard to do and gives you complete control over which
> > version of GTK is used by your app. We do this for Ardour (and now
> > Mixbus) (screenshots at http://ardour.org/ and
> > http://mixbus.harrisonconsoles.com/). Users download a single app, and
> > run it. No framework installation or maintainance.
> 
> I haven't built and made available updated frameworks because the 
> approach Richard used to create the first one (still hanging around on gtk-osx.org 
> , as previously noted elsewhere) didn't produce a result that I think 
> I can support. I have in mind a modification of ige-mac-bundler which 
> I think will provide better results, but other tasks have higher 
> priority at the moment.
> 
> Some others, including me, have done some work on the gtk-osx- 
> frameworks, and the network graph at github shows that my tree (http://github.com/jralls/gtk-osx-framework 
> ) is current with all of them . Do be aware that there are 3 branches, 
> of which master is probably the only one which will get you close 
> enough to use.
> 
> I also agree with Paul here: The Apple Framework idiom doesn't make 
> sense for cross-platform development. It uses special #include syntax 
> and special linking. It doesn't play well with pkg-config. Yes, those 
> are solvable problems, but why? The regular gnu autotools work very 
> well indeed on OSX, and one needs to use it anyway for building on 
> Linux. Why deal with another build chain just for the dubious benefit 
> of using XCode instead of emacs or vim?
> 
> Add to that that it's hard to build a non-trivial application using 
> only gtk+. You're going to need a bunch of other libraries, either 
> from gnome, gnu, or freedesktop. They're not going to be in 
> Frameworks, so you're going to have to integrate them the autotools 
> way, so what do you gain from having gtk+ in a set of frameworks?
> 
> There is one exception to which I'm quite sympathetic: PyGtk. At 
> present building a downloadable PyGtk app bundle is a royal pain, and 
> a PyGtk framework *might* be part of the solution.
> 
> Regards,
> John Ralls
> 
> _______________________________________________
> gtk-devel-list mailing list
> gtk-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/gtk-devel-list
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list gnome org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]