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




 EMAILING FOR THE GREATER GOOD
Join me

Subject: Re: Gtk-OSX Frameworks (was: Why are developers...)
From: ja...@juvul.com
Date: Tue, 10 Nov 2009 18:20:26 +0100
CC: gtk-devel-list@gnome.org
To: shashan...@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-recursiveMaking all 
in srcif /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; filibtool: 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.occ1obj: warnings being 
treated as errorsige-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 
castige-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 1make[1]: *** [all-recursive] 
Error 1make: *** [all] Error 2*** Error during phase build of 
ige-mac-integration: ########## Error running make   *** [10/11]
Anyone?
/Jacob


 EMAILING FOR THE GREATER GOOD
Join me

> From: jra...@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 <dac...@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

                                          
_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to