What possibly went wrong during build? This problem is 64-bit specific, because
it works fine in 32-bit install.

Is there any output on the console when starting galeon ?

after a clean, this is what I get:

----------------
** (galeon-bin:7714): WARNING **: I could not load the bookmarks file, will load
the default bookmarks from /home/portage/usr/share/galeon/default-bookmarks.xbel.
----------------

apart from this, there is no output in the terminal where galen is started from.

Only libraries I compiled with Forte were glib and gtk+-2.4. Everything else was
with gcc3.3. Mozilla won't compile if I don't compile glib and gtk+ that way.
All gnome(2.6.1) GTK2 applications work well and show menubar, but galeon
refuses to show menubar. It is as if the menubar is disabled in galeon because
everything else about galeon works perfectly. 

Does 'UI manager' in gtk-demo also work as usual?

Does hitting F10 in Galeon display the menu?

1. UI manager in gtk-demo works perfectly.
2. Hitting F10 doesn't display the menu. F9 gives the sidebar, so keys are
recognised.

Created attachment 28774 [details]
screenshot showing galeon without menubar

OK, I built the debug version and traced thru the code in galeon-window.c. It
seems to add the menubar to the dock alright, but it doesn't show up. Only
difference between usage of GTK by, let's say, gvim(which shows menus correctly)
and galeon is the libegg. Could there be problems with libegg component? any 
debugging tips?

is it possible to disable libegg component for testing?

Nope, it's required as much as gtk...  Can you test if epiphany or the libegg
test programs (need to get whole libegg from CVS) have similar problems?

epiphany doesn't compile for same reasons as galeon doesn't with Sun Forte. Not
interested in epiphany anyway.

I have never used cvs, can you give me few instructions on how to get libegg
from cvs for testing? thanks.

cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome login
[just hit enter for password]
cvs -d :pserver:anonymous@anoncvs.gnome.org:/cvs/gnome co libegg
cd libegg
./autogen.sh
make

Things to test are probably in libegg/toolbar and libegg/toolbareditor

login doesn't go thru with proxy. http_proxy is set, but I think cvs doesn't
read it. any idea?

CVS doesn't use HTTP, so I guess you can't get to it (silly firewall policy..) 
Anyway, I packaged libegg so that it's accessible through HTTP, you can get it
from http://tkomulai.iki.fi/libegg-20040622.tar.bz2

64-bit un-safe bugs in test_merge under libegg/menu...will report back soon.

-------------------------
$ ./test-dock 

(test-dock:3627): Egg-WARNING **: Unsupported docking strategy EGG_DOCK_NONE in
dock object of type EggDockItem

(test-dock:3627): Egg-WARNING **: Unsupported docking strategy EGG_DOCK_NONE in
dock object of type EggDockItem

(test-dock:3627): Egg-WARNING **: Unsupported docking strategy EGG_DOCK_NONE in
dock object of type EggDockItem

(test-dock:3627): Egg-WARNING **: Unsupported docking strategy EGG_DOCK_NONE in
dock object of type EggDockItem

(test-dock:3627): Egg-WARNING **: Unsupported docking strategy EGG_DOCK_NONE in
dock object of type EggDockItem

$ 
---------------------------------------
then it creates item1 (a text item), item2 (a floating button). It doesn't
create button3 and the item4 which is a text item again. They are not selectable
from the layout manager window. item2 disappears if I deselect it. I can't
select it again.

it seems like dock is not adding/showing some items...and that's the reason for
menu being not there.

the patch for 64-bit issue:

--- egg-menu-merge.c.ORG        2004-06-22 10:49:51.354435000 -0700
+++ egg-menu-merge.c    2004-06-22 10:49:32.905216000 -0700
@@ -732,7 +732,7 @@
                                 GError **error)
 {
   gchar *buffer;
-  gint length;
+  gsize length;
   guint res;
 
   if (!g_file_get_contents (filename, &buffer, &length, error))

This fix is already present in gtkuimanager.c (where egg-menu-merge.c was
moved/renamed)  Are you saying that should fix the dock, or did I misinterpret
something?

Woohoo!! solved!!

this patch brings the menus to life:

--- eggmarshalers.c     2004-06-22 14:25:46.120149000 -0700
+++ eggmarshalers.c.ORG 2004-06-22 14:25:40.922558000 -0700
@@ -39,7 +39,7 @@
 #define g_marshal_value_peek_ulong(v)    (v)->data[0].v_ulong
 #define g_marshal_value_peek_int64(v)    (v)->data[0].v_int64
 #define g_marshal_value_peek_uint64(v)   (v)->data[0].v_uint64
-#define g_marshal_value_peek_enum(v)     (v)->data[0].v_int
+#define g_marshal_value_peek_enum(v)     (v)->data[0].v_long
 #define g_marshal_value_peek_flags(v)    (v)->data[0].v_uint
 #define g_marshal_value_peek_float(v)    (v)->data[0].v_float
 #define g_marshal_value_peek_double(v)   (v)->data[0].v_double

---------------------------
this message: "(test-dock:3627): Egg-WARNING **: Unsupported docking strategy
EGG_DOCK_NONE in dock object of type EggDockItem" was the hint that the docking
position type was marshalled wrongly.

This probably is a glib bug.

that should fix the dock!

Looks reasonable.  I wonder if peek_flags() is also as broken...  That file is
generated by glib-mkenums, if you have a nice and compact test case for that,
I'm sure glib maintainers will appreciate it when you report a bug against glib ;)

OK, I think I was stupid in assuming enum's are long on 64-bit...they are not.
glib is doing the right thing. Its the libegg/eggmarshalers.c which is trying to
get the wrong things from internal data type of glib and screws up. If you
define macro G_ENABLE_DEBUG(which calls glib APIs, which surprises me because it
should be the other way around; debug should use the dirty method), the problem
with the docks is solved and menus of galeon make a comeback. I think libegg
should not make assumptions (which proved wrong in this case) about the internal
implementation of the GValue. It should respect glib's interfaces.

I haven't seen any side-effects of defining that macro. So, why don't we reverse
the meaning of that macro or define it by default, so that APIs are called.

is that a bug against glib still?....:)) because it looks like a generated
file...damn, there is so much to know...

I've filed bug 145015 against glib... NOTMYFAULT ;)

If I am reading this bug correctly, it is a glib bug, which is fixed bug the
change checked in for bug 145015. Please re-open if I am wrong :-)