x86_64 cross compiling
- From: "Jordan Crouse" <jordan crouse amd com>
- To: gconf-list gnome org
- Cc: orbit-list gnome org
- Subject: x86_64 cross compiling
- Date: Fri, 18 Jun 2004 12:04:44 -0600
Sorry for the lack of in depth debug detail in this message, I'm running gconf and friends on an embedded system, so in depth debugging is coming along slowly if at all.
Basically, the situation is this: I'm cross compiling gconf 2.6.2, orbit 2.10.2 and all associated libraries on an Gentoo based Opteron system targeted to a i486 machine. Because the Opteron is headless, I also needed to compile several 64 bit native packages as well (most notably orbit2 for a native 64 bit orbit-idl-2 compiler).
So, turning to the target machine, running anything related to the gconfd daemon results in the following (gconftool-2 --direct does not cause this to happen):
** ERROR **: Attempted to marshal a bogus / dead object 0xbffff860 type
I've tried this with gconftool-2, gconf-sanity-check-2, and rhythmbox (the only other gconf aware app I have on this system at the moment). All of them have slightly different addresses on the bogus type in question. GDB traces on all applications show a common ancestry as follows:
#6 0x40d31386 in g_log () from /usr/lib/libglib-2.0.so.0
#7 0x40996780 in ORBit_marshal_object () from /usr/lib/libORBit-2.so.0
#8 0x4099cfc3 in ORBit_marshal_value () from /usr/lib/libORBit-2.so.0
#9 0x409917e4 in ORBit_small_freekids () from /usr/lib/libORBit-2.so.0
#10 0x40992360 in ORBit_small_invoke_stub () from /usr/lib/libORBit-2.so.0
#11 0x4099212d in ORBit_small_invoke_stub_n () from /usr/lib/libORBit-2.so.0
#12 0x409aa7c2 in ORBit_c_stub_invoke () from /usr/lib/libORBit-2.so.0
#13 0x40b246d0 in ConfigServer_add_client () from /usr/lib/libgconf-2.so.4
#14 0x40b181e9 in gconf_engine_key_is_writable () from /usr/lib/libgconf-2.so.4
#15 0x40b182f3 in gconf_engine_key_is_writable () from /usr/lib/libgconf-2.so.4
#16 0x40b143ae in gconf_engine_pop_owner_usage () from /usr/lib/libgconf-2.so.4
#17 0x40b14508 in gconf_engine_pop_owner_usage () from /usr/lib/libgconf-2.so.4
#18 0x40b15378 in gconf_engine_get_fuller () from /usr/lib/libgconf-2.so.4
#19 0x40b156b2 in gconf_engine_get_entry () from /usr/lib/libgconf-2.so.4
ConfgServer_add_client() comes from from the compiled GConfX.idl code, and I assume this is where the problem lies (I'm not very familiar with Gnome, so please bear with me). Others using the same setup I am using have reported successful code with an 32 bit x86 cross compiling for x86 and ARM architectures. And obviously if there was a platform independent bug in the .idl it would have been discovered and fixed by now. So I would say that points at either the 64 bit platform or the lack of a complete set of native Gnome tools as the issue that I'm up against.
So my question for the experts is this: Is it possible that my native 64 bit orbit-idl-2 compiler is making assumptions about the offsets of the various variables, and thereby producing code that is confusing to a 32 bit machine? I do know that Orbit does care about the alignment of pointers (ORBIT_ALIGNOF_CORBA_POINTER and others), but like I said, I'm not very knowledgeable about how all this works, so I'm not sure if thats significant or a red herring.
It would be much easier for me to get more indepth debugging information if I could get some advice on where to look (I can't cram all the code on the system, but I might be able to get one or two packages on there if I needed to).
Please CC me, as I am on neither list. Thanks for your assistance.
Regards,
Jordan
PS: I do understand I could just chroot and use the i486 cross compiled orbit-idl-2 on the Opteron, but others might use this same setup for building for non-x86 architectures as well, so it would be nice to get to the root of the issue.
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]