tag:www.nabble.com,2006:forum-1385Nabble - Gnome - ORBit2008-11-13T03:14:37ZGnome CORBA ORB.tag:www.nabble.com,2006:post-20478819Re: error while cross-compiling ORBit2-2.14.1 for "ARM Cortex-A8"2008-11-13T03:14:37Z2008-11-13T03:14:37Zamit pundirThanks for your help.
<br>I cross-compiled it for my ARCH.
<br><br>I got your point from one of your earlier mails and replace the call
<br>of cross-compiled orbit-idl-2 with the native platforms
<br>/usr/bin/orbit-idl-2 and it builds fine.
<br><br>I just wish it wont break my next dependent builds :)
<br><br>Thanks and Regards
<br>Amit Pundir
<br><br><br>On Thu, Nov 13, 2008 at 3:22 PM, Amit Pundir <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20478819&i=0" target="_top" rel="nofollow">pundiramit@...</a>> wrote:
<div class='shrinkable-quote'><br>> Thanks for the values.
<br>>
<br>> I cached those values at configuration time and it is configured well
<br>> from there but now I got stuck at compilation.
<br>> It is trying to execute a cross-compiled binary(meant for arm) and fails.
<br>>
<br>> Here is the appropriate log:
<br>>
<br>> --------------------------------------
<br>> Making all in orb-core
<br>> make[8]: Entering directory
<br>> `/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit/orb-core'
<br>> (rm -f corba-defs.h corba-defs-stubs.c corba-defs-skels.c
<br>> corba-defs-common.c corba-defs-imodule.c corba-defs-skelimpl.c ||
<br>> true) > /dev/null
<br>> ../../../src/idl-compiler/orbit-idl-2 -I../../../src/idl/CORBA_PIDL
<br>> -I../../../src/idl/CORBA -I../../../src/idl/interop
<br>> -I../../../src/orb/orb-core --noskels --nodefskels --nostubs --noidata
<br>> --nocommon --showcpperrors --define=Object=OObject
<br>> --define=TypeCode=TTypeCode --deps ./.deps/corba-defs.idl.P
<br>> ../../../src/orb/orb-core/corba-defs.idl
<br>> /bin/bash: ../../../src/idl-compiler/orbit-idl-2: cannot execute binary file
<br>> make[8]: *** [corba-defs.h] Error 126
<br>> make[8]: Leaving directory
<br>> `/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit/orb-core'
<br>> make[7]: *** [all-recursive] Error 1
<br>> make[7]: Leaving directory
<br>> `/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit'
<br>> make[6]: *** [all] Error 2
<br>> make[6]: Leaving directory
<br>> `/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit'
<br>> make[5]: *** [all-recursive] Error 1
<br>> make[5]: Leaving directory
<br>> `/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include'
<br>> make[4]: *** [all] Error 2
<br>> --------------------------------------
<br>>
<br>> Any work around for this??
<br>>
<br>> Once in a while when I get situation like this i.e. the compilation
<br>> fails during building tests or some checks, I used to skip
<br>> building/installing that part of the program.
<br>> Should I skip building "orb-core" part or what ? Also, I'm not sure
<br>> what purpose "orb-core" source solves in ORBit package.
<br>>
<br>> Thank you very much again for CORBA variables.
<br>>
<br>>
<br>> Regards
<br>> Amit Pundir
<br>>
<br>>
<br>> On Thu, Nov 13, 2008 at 3:05 PM, Frank Rehberger <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20478819&i=1" target="_top" rel="nofollow">Frank.Rehberger@...</a>> wrote:
<br>>> -----BEGIN PGP SIGNED MESSAGE-----
<br>>> Hash: SHA1
<br>>>
<br>>> Amit Pundir wrote:
<br>>>> Hello team,
<br>>>>
<br>>>> First of all please excuse me for my questions if they seem trivial or
<br>>>> if they have already been discussed on this mailing list though I have
<br>>>> done much googling for this information.
<br>>>>
<br>>>> I'm trying to cross-compile ORBit2-2.14.13 for my ARM machine using
<br>>>> code-sourcery gnu toolchain. I'm getting the following error during
<br>>>> configuration.
<br>>>>
<br>>>> ----------------------------
<br>>>> checking whether byte ordering is bigendian... no
<br>>>> checking alignment of CORBA_octet... 0
<br>>>> configure: error: Failed to find alignment. Check config.log for details.
<br>>>> ----------------------------
<br>>>>
<br>>>> In config.log I found that compiler is not able to set the alignment
<br>>>> of CORBA_octet and ac_cv_alignof_CORBA_octet is set to 0. Thats why
<br>>>> I'm getting this error.
<br>>>>
<br>>>> Similarly I'm sure I will get the same error while setting the
<br>>>> alignment of CORBA_boolean, char, wchar etc..
<br>>>>
<br>>>> Are there any known values for the following variables which I can
<br>>>> cache during configuration process?
<br>>>>
<br>>> well, the alignment is defined by CORBA-Spec, octet and structs and
<br>>> others are not aligned, probably expressed as "1"
<br>>>> alignment of CORBA_octet 1
<br>>>> alignment of CORBA_boolean 4 (bool is represented as long)
<br>>>> alignment of CORBA_char 1
<br>>>> alignment of CORBA_wchar 2 (same as short)
<br>>>> alignment of CORBA_short 2
<br>>>> alignment of CORBA_long 4
<br>>>> alignment of CORBA_long_long 8
<br>>>> alignment of CORBA_float 4
<br>>>> alignment of CORBA_double 8
<br>>>> alignment of CORBA_long_double ? (probably 8)
<br>>>> alignment of CORBA_struct 1
<br>>>> alignment of CORBA_pointer (not specified by CORBA, probably platform
<br>>> specific)
<br>>>>
<br>>> Hope that helps.
<br>>>
<br>>> Regards, frank
<br>>> -----BEGIN PGP SIGNATURE-----
<br>>> Version: GnuPG v1.2.2 (MingW32)
<br>>> Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_top" rel="nofollow">http://enigmail.mozdev.org</a><br>>>
<br>>> iD8DBQFJG/Tk99BSmbIl7S0RAqmSAKC+yEIS8oJjgmDeKnR0W0PWVgK/WQCgv6xk
<br>>> kbvdx4jERv7b18aSFv3Fj/o=
<br>>> =QDXO
<br>>> -----END PGP SIGNATURE-----
<br>>>
<br>>>
<br>>
</div>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20478819&i=2" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20477719Re: error while cross-compiling ORBit2-2.14.1 for "ARM Cortex-A8"2008-11-13T01:52:28Z2008-11-13T01:52:28Zamit pundirThanks for the values.
<br><br>I cached those values at configuration time and it is configured well
<br>from there but now I got stuck at compilation.
<br>It is trying to execute a cross-compiled binary(meant for arm) and fails.
<br><br>Here is the appropriate log:
<br><br>--------------------------------------
<br>Making all in orb-core
<br>make[8]: Entering directory
<br>`/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit/orb-core'
<br>(rm -f corba-defs.h corba-defs-stubs.c corba-defs-skels.c
<br>corba-defs-common.c corba-defs-imodule.c corba-defs-skelimpl.c ||
<br>true) > /dev/null
<br>../../../src/idl-compiler/orbit-idl-2 -I../../../src/idl/CORBA_PIDL
<br>-I../../../src/idl/CORBA -I../../../src/idl/interop
<br>-I../../../src/orb/orb-core --noskels --nodefskels --nostubs --noidata
<br>--nocommon --showcpperrors --define=Object=OObject
<br>--define=TypeCode=TTypeCode --deps ./.deps/corba-defs.idl.P
<br>../../../src/orb/orb-core/corba-defs.idl
<br>/bin/bash: ../../../src/idl-compiler/orbit-idl-2: cannot execute binary file
<br>make[8]: *** [corba-defs.h] Error 126
<br>make[8]: Leaving directory
<br>`/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit/orb-core'
<br>make[7]: *** [all-recursive] Error 1
<br>make[7]: Leaving directory
<br>`/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit'
<br>make[6]: *** [all] Error 2
<br>make[6]: Leaving directory
<br>`/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include/orbit'
<br>make[5]: *** [all-recursive] Error 1
<br>make[5]: Leaving directory
<br>`/home/amit/omap35xx/ti/src_gnome_build/ORBit2-2.14.13/include'
<br>make[4]: *** [all] Error 2
<br>--------------------------------------
<br><br>Any work around for this??
<br><br>Once in a while when I get situation like this i.e. the compilation
<br>fails during building tests or some checks, I used to skip
<br>building/installing that part of the program.
<br>Should I skip building "orb-core" part or what ? Also, I'm not sure
<br>what purpose "orb-core" source solves in ORBit package.
<br><br>Thank you very much again for CORBA variables.
<br><br><br>Regards
<br>Amit Pundir
<br><br><br>On Thu, Nov 13, 2008 at 3:05 PM, Frank Rehberger <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20477719&i=0" target="_top" rel="nofollow">Frank.Rehberger@...</a>> wrote:
<div class='shrinkable-quote'><br>> -----BEGIN PGP SIGNED MESSAGE-----
<br>> Hash: SHA1
<br>>
<br>> Amit Pundir wrote:
<br>>> Hello team,
<br>>>
<br>>> First of all please excuse me for my questions if they seem trivial or
<br>>> if they have already been discussed on this mailing list though I have
<br>>> done much googling for this information.
<br>>>
<br>>> I'm trying to cross-compile ORBit2-2.14.13 for my ARM machine using
<br>>> code-sourcery gnu toolchain. I'm getting the following error during
<br>>> configuration.
<br>>>
<br>>> ----------------------------
<br>>> checking whether byte ordering is bigendian... no
<br>>> checking alignment of CORBA_octet... 0
<br>>> configure: error: Failed to find alignment. Check config.log for details.
<br>>> ----------------------------
<br>>>
<br>>> In config.log I found that compiler is not able to set the alignment
<br>>> of CORBA_octet and ac_cv_alignof_CORBA_octet is set to 0. Thats why
<br>>> I'm getting this error.
<br>>>
<br>>> Similarly I'm sure I will get the same error while setting the
<br>>> alignment of CORBA_boolean, char, wchar etc..
<br>>>
<br>>> Are there any known values for the following variables which I can
<br>>> cache during configuration process?
<br>>>
<br>> well, the alignment is defined by CORBA-Spec, octet and structs and
<br>> others are not aligned, probably expressed as "1"
<br>>> alignment of CORBA_octet 1
<br>>> alignment of CORBA_boolean 4 (bool is represented as long)
<br>>> alignment of CORBA_char 1
<br>>> alignment of CORBA_wchar 2 (same as short)
<br>>> alignment of CORBA_short 2
<br>>> alignment of CORBA_long 4
<br>>> alignment of CORBA_long_long 8
<br>>> alignment of CORBA_float 4
<br>>> alignment of CORBA_double 8
<br>>> alignment of CORBA_long_double ? (probably 8)
<br>>> alignment of CORBA_struct 1
<br>>> alignment of CORBA_pointer (not specified by CORBA, probably platform
<br>> specific)
<br>>>
<br>> Hope that helps.
<br>>
<br>> Regards, frank
<br>> -----BEGIN PGP SIGNATURE-----
<br>> Version: GnuPG v1.2.2 (MingW32)
<br>> Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_top" rel="nofollow">http://enigmail.mozdev.org</a><br>>
<br>> iD8DBQFJG/Tk99BSmbIl7S0RAqmSAKC+yEIS8oJjgmDeKnR0W0PWVgK/WQCgv6xk
<br>> kbvdx4jERv7b18aSFv3Fj/o=
<br>> =QDXO
<br>> -----END PGP SIGNATURE-----
<br>>
<br>>
</div>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20477719&i=1" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20477459Re: error while cross-compiling ORBit2-2.14.1 for "ARM Cortex-A8"2008-11-13T01:35:32Z2008-11-13T01:35:32ZFrank Rehberger-----BEGIN PGP SIGNED MESSAGE-----
<br>Hash: SHA1
<br>
<br>Amit Pundir wrote:
<div class='shrinkable-quote'><br>> Hello team,
<br>>
<br>> First of all please excuse me for my questions if they seem trivial or
<br>> if they have already been discussed on this mailing list though I have
<br>> done much googling for this information.
<br>>
<br>> I'm trying to cross-compile ORBit2-2.14.13 for my ARM machine using
<br>> code-sourcery gnu toolchain. I'm getting the following error during
<br>> configuration.
<br>>
<br>> ----------------------------
<br>> checking whether byte ordering is bigendian... no
<br>> checking alignment of CORBA_octet... 0
<br>> configure: error: Failed to find alignment. Check config.log for details.
<br>> ----------------------------
<br>>
<br>> In config.log I found that compiler is not able to set the alignment
<br>> of CORBA_octet and ac_cv_alignof_CORBA_octet is set to 0. Thats why
<br>> I'm getting this error.
<br>>
<br>> Similarly I'm sure I will get the same error while setting the
<br>> alignment of CORBA_boolean, char, wchar etc..
<br>>
<br>> Are there any known values for the following variables which I can
<br>> cache during configuration process?
<br>>
</div>well, the alignment is defined by CORBA-Spec, octet and structs and
<br>others are not aligned, probably expressed as "1"
<div class='shrinkable-quote'><br>> alignment of CORBA_octet 1
<br>> alignment of CORBA_boolean 4 (bool is represented as long)
<br>> alignment of CORBA_char 1
<br>> alignment of CORBA_wchar 2 (same as short)
<br>> alignment of CORBA_short 2
<br>> alignment of CORBA_long 4
<br>> alignment of CORBA_long_long 8
<br>> alignment of CORBA_float 4
<br>> alignment of CORBA_double 8
<br>> alignment of CORBA_long_double ? (probably 8)
<br>> alignment of CORBA_struct 1
<br>> alignment of CORBA_pointer (not specified by CORBA, probably platform
</div>specific)
<br>>
<br>Hope that helps.
<br><br>Regards, frank
<br>-----BEGIN PGP SIGNATURE-----
<br>Version: GnuPG v1.2.2 (MingW32)
<br>Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org" target="_top" rel="nofollow">http://enigmail.mozdev.org</a><br>
<br>iD8DBQFJG/Tk99BSmbIl7S0RAqmSAKC+yEIS8oJjgmDeKnR0W0PWVgK/WQCgv6xk
<br>kbvdx4jERv7b18aSFv3Fj/o=
<br>=QDXO
<br>-----END PGP SIGNATURE-----
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20477459&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20475964error while cross-compiling ORBit2-2.14.1 for "ARM Cortex-A8"2008-11-12T23:32:51Z2008-11-12T23:32:51Zamit pundirHello team,
<br><br>First of all please excuse me for my questions if they seem trivial or
<br>if they have already been discussed on this mailing list though I have
<br>done much googling for this information.
<br><br>I'm trying to cross-compile ORBit2-2.14.13 for my ARM machine using
<br>code-sourcery gnu toolchain. I'm getting the following error during
<br>configuration.
<br><br>----------------------------
<br>checking whether byte ordering is bigendian... no
<br>checking alignment of CORBA_octet... 0
<br>configure: error: Failed to find alignment. Check config.log for details.
<br>----------------------------
<br><br>In config.log I found that compiler is not able to set the alignment
<br>of CORBA_octet and ac_cv_alignof_CORBA_octet is set to 0. Thats why
<br>I'm getting this error.
<br><br>Similarly I'm sure I will get the same error while setting the
<br>alignment of CORBA_boolean, char, wchar etc..
<br><br>Are there any known values for the following variables which I can
<br>cache during configuration process?
<br><br>alignment of CORBA_octet
<br>alignment of CORBA_boolean
<br>alignment of CORBA_char
<br>alignment of CORBA_wchar
<br>alignment of CORBA_short
<br>alignment of CORBA_long
<br>alignment of CORBA_long_long
<br>alignment of CORBA_float
<br>alignment of CORBA_double
<br>alignment of CORBA_long_double
<br>alignment of CORBA_struct
<br>alignment of CORBA_pointer
<br><br>Any help on this will be appreciated.
<br>Thanks for your concern.
<br><br>Regards
<br>Amit Pundir
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20475964&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20105161Re: win32 native build2008-10-22T00:08:03Z2008-10-22T00:08:03ZMarcelo VanzinOn Tue, Oct 21, 2008 at 11:35 PM, Bart Vanherck
<br><<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20105161&i=0" target="_top" rel="nofollow">bvanherck@...</a>> wrote:
<br>> True, the simple hello world application crached when I runned them. I know
<br>> now that the solution is try to build the lib with MVC and patch it to
<br>> export the variables and functions and so on ...
<br><br>If you want to play with that, you may want to take a look at
<br><a href="http://bugzilla.gnome.org/show_bug.cgi?id=537328" target="_top" rel="nofollow">http://bugzilla.gnome.org/show_bug.cgi?id=537328</a>. It's been a few
<br>months since I touched that code, but it worked for me with MSVC.
<br><br>(I have my own hacked together makefiles to compile orbit on Win32, I
<br>could send them to you but they're not pretty.)
<br><br>--
<br>Marcelo Vanzin
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20105161&i=1" target="_top" rel="nofollow">mmvgroups@...</a>
<br>"Life's too short to drink cheap beer."
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20105161&i=2" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20104833Re: win32 native build2008-10-21T23:35:48Z2008-10-21T23:35:48ZBart Vanherck-4Tor Lillqvist wrote:
<div class='shrinkable-quote'><br>>> It seems to work, at least for function calls. The data structures remain
<br>>> still unresolved.
<br>>>
<br>>
<br>> I think that must be because the corresponding declarations in the
<br>> headers don't have the __declspec(dllimport) attributes. gcc can
<br>> manage without, MSVC can't.
<br>>
<br>>
<br>>> My linkage gives unresolved for this (DATA) symbols. The solution was that I
<br>>> just needed to remove "DATA" before building the lib file. But my little
<br>>> test program links now.
<br>>>
<br>>
<br>> But it is probable that actual use of these variables without MSVC
<br>> knowing that they are actually imported from a DLL produces bogus
<br>> results or even crashes? Does the program actually work?
<br>>
<br>> --tml
<br>>
<br>>
</div>True, the simple hello world application crached when I runned them. I
<br>know now that the solution is try to build the lib with MVC and patch it
<br>to export the variables and functions and so on ...
<br><br>Bart
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20104833&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20044440Re: win32 native build2008-10-17T23:10:13Z2008-10-17T23:10:13ZTor Lillqvist> It seems to work, at least for function calls. The data structures remain
<br>> still unresolved.
<br><br>I think that must be because the corresponding declarations in the
<br>headers don't have the __declspec(dllimport) attributes. gcc can
<br>manage without, MSVC can't.
<br><br>> My linkage gives unresolved for this (DATA) symbols. The solution was that I
<br>> just needed to remove "DATA" before building the lib file. But my little
<br>> test program links now.
<br><br>But it is probable that actual use of these variables without MSVC
<br>knowing that they are actually imported from a DLL produces bogus
<br>results or even crashes? Does the program actually work?
<br><br>--tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20044440&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20034071Re: win32 native build2008-10-17T06:33:12Z2008-10-17T06:33:12ZBart Vanherck-4Thank you.
<br><br>It seems to work, at least for function calls. The data structures
<br>remain still unresolved.
<br><br>In the def file for example I see this:
<br>TC_CORBA_short_struct DATA
<br>TC_CORBA_string_struct DATA
<br>TC_CORBA_unsigned_long_long_struct DATA
<br>TC_CORBA_unsigned_long_struct DATA
<br>TC_CORBA_unsigned_short_struct DATA
<br><br>My linkage gives unresolved for this (DATA) symbols. The solution was
<br>that I just needed to remove "DATA" before building the lib file. But my
<br>little test program links now.
<br><br>kind regards,
<br><br>Bart
<br><br>Tor Lillqvist wrote:
<div class='shrinkable-quote'><br>>> I already downloaded the
<br>>> ORBit2-dev_2.4.16-1_win32.zip from the gnome ftp site, but there were no lib
<br>>> files included.
<br>>>
<br>>
<br>> You can produce one for instance like this:
<br>>
<br>> download <a href="http://tml.pp.fi/pexports-0.44.zip" target="_top" rel="nofollow">http://tml.pp.fi/pexports-0.44.zip</a>, unpack, put pexports.exe
<br>> somewhere in %PATH% . pexports also comes with mingw.
<br>> cd foo\lib
<br>> pexports ..\bin\libORBit-2-0.dll >ORBit-2.def
<br>> lib -def:ORBit-2.def -machine:x86 -out:ORBit-2.lib
<br>>
<br>> where lib is lib.exe that comes with MSVC.
<br>>
<br>> You can also use link -dump -exports instead of pexports, but then you
<br>> will have to edit the output file into .def syntax, and the exported
<br>> variables won't be marked with the DATA keyword, which probably is
<br>> very relevant for the produced import library to be useful with MSVC.
<br>>
<br>> Note that I have never used ORBit2 with MSVC-built code myself, I only
<br>> told above how to produce an MS import library.
<br>>
<br>> --tml
<br>>
<br>>
</div><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20034071&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20019234Re: win32 native build2008-10-16T10:40:21Z2008-10-16T10:40:21ZTor Lillqvist> download <a href="http://tml.pp.fi/pexports-0.44.zip" target="_top" rel="nofollow">http://tml.pp.fi/pexports-0.44.zip</a>, unpack, put pexports.exe
<br>> somewhere in %PATH% .
<br><br>I misremembered, that file contains pexports sources, no executable...
<br>(and compiling it requires flex and bison (or lex and yacc)). So look
<br>for pexports.exe from mingw instead.
<br><br>--tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20019234&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20019136Re: win32 native build2008-10-16T10:37:19Z2008-10-16T10:37:19ZTor Lillqvist> I already downloaded the
<br>> ORBit2-dev_2.4.16-1_win32.zip from the gnome ftp site, but there were no lib
<br>> files included.
<br><br>You can produce one for instance like this:
<br><br>download <a href="http://tml.pp.fi/pexports-0.44.zip" target="_top" rel="nofollow">http://tml.pp.fi/pexports-0.44.zip</a>, unpack, put pexports.exe
<br>somewhere in %PATH% . pexports also comes with mingw.
<br>cd foo\lib
<br>pexports ..\bin\libORBit-2-0.dll >ORBit-2.def
<br>lib -def:ORBit-2.def -machine:x86 -out:ORBit-2.lib
<br><br>where lib is lib.exe that comes with MSVC.
<br><br>You can also use link -dump -exports instead of pexports, but then you
<br>will have to edit the output file into .def syntax, and the exported
<br>variables won't be marked with the DATA keyword, which probably is
<br>very relevant for the produced import library to be useful with MSVC.
<br><br>Note that I have never used ORBit2 with MSVC-built code myself, I only
<br>told above how to produce an MS import library.
<br><br>--tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20019136&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-20014855win32 native build2008-10-16T07:06:23Z2008-10-16T07:06:23ZBart Vanherck-4Hello all,
<br><br>I march 2008 there were some mailings about letting ORBit work with MS
<br>compilers. What is the current state on this? Is there something that
<br>still needs to be done ?
<br><br>I want to port some existing code to work on win32. I already downloaded
<br>the ORBit2-dev_2.4.16-1_win32.zip from the gnome ftp site, but there
<br>were no lib files included.
<br><br>kind regards,
<br><br>Bart
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=20014855&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-19511682Re: I just missed the train for 2.14.152008-09-16T06:20:28Z2008-09-16T06:20:28ZJules Colding<br>On 16/09/2008, at 14.59, Jules Colding wrote:
<br><br>> Hi,
<br>>
<br>> My fixes for #538388 and #552323 apparently just missed the train.
<br>> Could we please have a 2.14.16 in the near future?
<br><br>No worries, Kjartan has been kind to do 2.14.16 in the close future.
<br><br>Thanks :-)
<br> jules
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19511682&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-19511359I just missed the train for 2.14.152008-09-16T05:59:28Z2008-09-16T05:59:28ZJules ColdingHi,
<br><br>My fixes for #538388 and #552323 apparently just missed the train.
<br>Could we please have a 2.14.16 in the near future?
<br><br><br>Thanks,
<br> jules
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19511359&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-19168015Re: Error processing an idl file.2008-08-26T11:47:15Z2008-08-26T11:47:15ZJules ColdingHi,
<br><br>On 26/08/2008, at 20.31, Javier Fernandez Garcia-Boente wrote:
<br>> The strange thing is that i have not that error using Debian/stable
<br>> neither Ubuntu/Hardy. That error appears only in Debian/testing.
<br><br>It must be something in Debian/testing as it compiles just fine for me
<br>on darwin. I'm also using 2.14.12 as you are.
<br><br>Best regards,
<br> jules
<br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19168015&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-19167701Error processing an idl file.2008-08-26T11:31:44Z2008-08-26T11:31:44ZJavier FernandezHi,
<br><br>Im getting an strange error processing a very simple IDL file:
<br><br>#ifndef _FCOMMONMODULE_IDL_
<br>#define _FCOMMONMODULE_IDL_
<br><br>module f_common {
<br><br>enum FisterraErrorType {
<br> FisterraFailed, FisterraNoPermission,
<br> FisterraBadAddress, FisterraParseError, FisterraCorrupt,
<br> FisterraTypeMismatch, FisterraNoDatabaseAvailable,
<br> FisterraInShutdown, FisterraDatabaseTransactionError,
<br> FisterraDatabaseOperationError, FisterraDatabaseUpdateConflict,
<br> FisterraDatabaseConnectionError, FisterraEDIError
<br>};
<br><br>exception FisterraException {
<br> FisterraErrorType err_no;
<br> string message;
<br>};
<br>
<br>};
<br><br>#endif /* _FCOMMONMODULE_IDL_ */
<br><br>This IDL just define several error types for using them in a
<br>client/server application.
<br><br>Im compiling gthis IDL file using:
<br><br>/usr/bin/orbit-idl-2 --onlytop -I . ./f_com_corba_common.idl
<br>
<br>Im receiving the following error:
<br><br>orbit-idl-2 2.14.12 compiling
<br> mode, hide preprocessor errors, passes: stubs skels common headers
<br><br>Processing file ./f_com_corba_common.idl
<br>**
<br>** ERROR:(orbit-idl-c-headers.c:300):ch_output_types: assertion failed:
<br>(htail && strlen (htail) >= 2)
<br>Aborted
<br><br>If i remove the "--onlytop" option, the file is successfully processed.
<br>However, i need this option in other IDL files that i have to use later,
<br>in which additional IDL files are included using the "#include"
<br>directive.
<br><br>The strange thing is that i have not that error using Debian/stable
<br>neither Ubuntu/Hardy. That error appears only in Debian/testing.
<br><br>Thanks for your help.
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=19167701&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18689520Re: Memory leak on CORBA_String_dup2008-07-28T05:34:34Z2008-07-28T05:34:34ZJules ColdingHi arijit,
<br><br>On 28/07/2008, at 14.28, arijit wrote:
<div class='shrinkable-quote'><br>> On 28/07/2008, at 11.29, arijit wrote:
<br>>
<br>>> Hi,
<br>>> I am using ORBit2 on server side and OpenORB on the client side.
<br>>> The ORBit2 returns a string by doing CORBA_String_sup of a const
<br>>> char *. In OpenORB, I take care of making sure the retruned value is
<br>>> null-ified (though, I believe, it cannot contribute to the server
<br>>> leaking memory!!).
<br>>> I have confirmed that the leak is with the String being passed,
<br>>> by, increasing the size of the String being returned, and seeing the
<br>>> server leak increasing significantly!
<br>>> Am I missing something, or am I going horribly wrong somewhere?
<br>>> Any help is much appreciated!!
<br>>
<br>> Seeing the server side method code will help.
<br>>
<br>> Best regards,
<br>> jules
<br>>
<br>> Hi,
<br>> Here is the code snippet:
<br>>
<br>> static uancorba_SessionID
<br>> impl_uancorba_SessionManager_createConfigSession
<br>> (impl_POA_uancorba_SessionManager *servant,
<br>> CORBA_Environment *ev)
<br>> {
<br>> uancorba_SessionID retval;
<br>> retval = CORBA_string_dup("TEST THIS OUT FIRST");
<br>> return (retval);
<br>> }
<br>>
<br>> In the idl, SessionID is defined, thus:
<br>> module uancorba {
<br>>
<br>> /**
<br>> * The SessionID is a unique identifier used to represent the
<br>> user's session.
<br>> */
<br>> typedef string SessionID;
<br>> .....
<br>>
<br>> }
<br>>
<br>> I am using ORBit2 version number: 2.12.4.
</div><br>Your code is correct and should not leak but you are using an ancient
<br>version of ORBit2. Please try again with something newer like "2.14.13".
<br><br>Best regards,
<br> jules
<br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18689520&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18689395Re: Memory leak on CORBA_String_dup2008-07-28T05:28:17Z2008-07-28T05:28:17Zarijit-3On 28/07/2008, at 11.29, arijit wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>> I am using ORBit2 on server side and OpenORB on the client side.
<br>> The ORBit2 returns a string by doing CORBA_String_sup of a const
<br>> char *. In OpenORB, I take care of making sure the retruned value is
<br>> null-ified (though, I believe, it cannot contribute to the server
<br>> leaking memory!!).
<br>> I have confirmed that the leak is with the String being passed,
<br>> by, increasing the size of the String being returned, and seeing the
<br>> server leak increasing significantly!
<br>> Am I missing something, or am I going horribly wrong somewhere?
<br>> Any help is much appreciated!!
</div><br>Seeing the server side method code will help.
<br><br>Best regards,
<br> jules
<br><br>Hi,
<br> Here is the code snippet:
<br><br>static uancorba_SessionID
<br>impl_uancorba_SessionManager_createConfigSession(impl_POA_uancorba_SessionManager *servant,
<br>CORBA_Environment *ev)
<br>{
<br> uancorba_SessionID retval;
<br> retval = CORBA_string_dup("TEST THIS OUT FIRST");
<br> return (retval);
<br>}
<br><br>In the idl, SessionID is defined, thus:
<br>module uancorba {
<br><br> /**
<br> * The SessionID is a unique identifier used to represent the user's session.
<br> */
<br> typedef string SessionID;
<br>.....
<br><br>}
<br><br>I am using ORBit2 version number: 2.12.4.
<br><br>Thanks a ton for all your help!!
<br><br>-Arijit
<br><br><br><br>
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18689395&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18688269Re: Memory leak on CORBA_String_dup2008-07-28T04:15:44Z2008-07-28T04:15:44ZJules Colding<br>On 28/07/2008, at 11.29, arijit wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>> I am using ORBit2 on server side and OpenORB on the client side.
<br>> The ORBit2 returns a string by doing CORBA_String_sup of a const
<br>> char *. In OpenORB, I take care of making sure the retruned value is
<br>> null-ified (though, I believe, it cannot contribute to the server
<br>> leaking memory!!).
<br>> I have confirmed that the leak is with the String being passed,
<br>> by, increasing the size of the String being returned, and seeing the
<br>> server leak increasing significantly!
<br>> Am I missing something, or am I going horribly wrong somewhere?
<br>> Any help is much appreciated!!
</div><br>Seeing the server side method code will help.
<br><br>Best regards,
<br> jules
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18688269&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18686880Memory leak on CORBA_String_dup2008-07-28T02:29:08Z2008-07-28T02:29:08Zarijit-3Hi,
<br> I am using ORBit2 on server side and OpenORB on the client side. The ORBit2 returns a string by doing CORBA_String_sup of a const char *. In OpenORB, I take care of making sure the retruned value is null-ified (though, I believe, it cannot contribute to the server leaking memory!!).
<br> I have confirmed that the leak is with the String being passed, by, increasing the size of the String being returned, and seeing the server leak increasing significantly!
<br> Am I missing something, or am I going horribly wrong somewhere?
<br> Any help is much appreciated!!
<br>-Arijit
<br><br><br><br>
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18686880&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18531047Re: Crosscompiling ORbit2 for ARM92008-07-18T07:52:28Z2008-07-18T07:52:28ZFrank Rehberger<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
-----BEGIN PGP SIGNED MESSAGE----- <br>
Hash: SHA1 <br>
<br>
Hi Giraut,<br>
<br>
it is a while ago I cross compiled orbit, but probably this is related
to the generated code from IDL files, such as "orbit-interface.idl" The
cross compiled orbit-idl executable will not be able to do the job on
your host-system. You will need to define native orbit-idl compiler on
your host-system, to do the idl-code-generation job to generate the
code from IDL files for your target system.<br>
<br>
Cross compiling should be done in two steps:<br>
1. Compile Orbit2 native for your host system<br>
2. Cross compile Orbit2, but tweak the environment to use the
orbit-idl-2 executable from step 1.<br>
2(alternative). It might also help to copy the generated files form
step 1 into x-compile workspace, but not sure if this might do AFAICS,
the generated code should be generic, not depending on endianess.<br>
<br>
Hope that helps, Frank<br>
<br>
Hope that helps,<br>
giraut benoit wrote:<br>
| Hello<br>
|<br>
| I have a error during the compilation of Orbit2 in a scratchbox
context :<br>
| The orbit-interface-common.c is missing so the compilation fail.<br>
|<br>
| Did someone get this error before ?<br>
|<br>
| Thx benoit<br>
|<br>
|<br>
| /bin/sh ../../../libtool --tag=CC --mode=compile gcc
-DHAVE_CONFIG_H -I. -I../../.. -I. -I. -I../../../include
-I../../../include/orbit/orb-core -I../../../include
-I../../../include/orbit/orb-core
-DORBIT_TYPELIB_DIR=\""/usr/local/lib/orbit-2.0"\"
-DORBIT2_INTERNAL_API -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -DG_DISABLE_DEPRECATED -I../../../linc2/include
-I../../../linc2/include -pthread -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -g -O2
-Werror-implicit-function-declaration -MT orbit-interface-common.lo
-MD -MP -MF .deps/orbit-interface-common.Tpo -c -o
orbit-interface-common.lo orbit-interface-common.c<br>
| gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I. -I../../../include
-I../../../include/orbit/orb-core -I../../../include
-I../../../include/orbit/orb-core
-DORBIT_TYPELIB_DIR=\"/usr/local/lib/orbit-2.0\" -DORBIT2_INTERNAL_API
-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations
-DG_DISABLE_DEPRECATED -I../../../linc2/include
-I../../../linc2/include -pthread -I/usr/local/include/glib-2.0
-I/usr/local/lib/glib-2.0/include -g -O2
-Werror-implicit-function-declaration -MT orbit-interface-common.lo -MD
-MP -MF .deps/orbit-interface-common.Tpo -c orbit-interface-common.c
-fPIC -DPIC -o .libs/orbit-interface-common.o<br>
| sbox-arm-linux-gcc: orbit-interface-common.c: No such file or
directory<br>
| sbox-arm-linux-gcc: no input files<br>
| make[5]: *** [orbit-interface-common.lo] Error 1<br>
| make[5]: Leaving directory
`/home/benoit/ORBit2-2.14.13/src/orb/orb-core'<br>
| make[4]: *** [all] Error 2<br>
| make[4]: Leaving directory
`/home/benoit/ORBit2-2.14.13/src/orb/orb-core'<br>
| make[3]: *** [all-recursive] Error 1<br>
| make[3]: Leaving directory `/home/benoit/ORBit2-2.14.13/src/orb'<br>
| make[2]: *** [all-recursive] Error 1<br>
| make[2]: Leaving directory `/home/benoit/ORBit2-2.14.13/src'<br>
| make[1]: *** [all-recursive] Error 1<br>
| make[1]: Leaving directory `/home/benoit/ORBit2-2.14.13'<br>
| make: *** [all] Error 2<br>
|<br>
<br>
|<br>
| -------------------------<br>
|<br>
| _______________________________________________<br>
| orbit-list mailing list<br>
| <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18531047&i=0" target="_top" rel="nofollow">orbit-list@...</a><br>
| <a class="moz-txt-link-freetext" href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br>
<br>
-----BEGIN PGP SIGNATURE----- <br>
Version: GnuPG v1.2.2 (MingW32) <br>
Comment: Using GnuPG with Mozilla - <a class="moz-txt-link-freetext" href="http://enigmail.mozdev.org" target="_top" rel="nofollow">http://enigmail.mozdev.org</a> <br>
<br>
iD8DBQFIgK4i99BSmbIl7S0RAsEXAKCVCNtJ3MPJ7Z0ufV/1axvlvBmbVQCdEhlJ <br>
TEq4b2W2bM0W5svyQvvaFw4= <br>
=7Jq/ <br>
-----END PGP SIGNATURE----- <br>
<br>
</body>
</html>
<br />_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18531047&i=1" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18527985Crosscompiling ORbit2 for ARM92008-07-18T05:17:30Z2008-07-18T05:17:30Zgiraut benoit<div dir="ltr">Hello<br><br>I have a error during the compilation of Orbit2 in a scratchbox context :<br>The orbit-interface-common.c is missing so the compilation fail.<br><br>Did someone get this error before ? <br><br>Thx benoit<br>
<br><br>/bin/sh ../../../libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I. -I../../../include -I../../../include/orbit/orb-core -I../../../include -I../../../include/orbit/orb-core -DORBIT_TYPELIB_DIR=\""/usr/local/lib/orbit-2.0"\" -DORBIT2_INTERNAL_API -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -DG_DISABLE_DEPRECATED -I../../../linc2/include -I../../../linc2/include -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Werror-implicit-function-declaration -MT orbit-interface-common.lo -MD -MP -MF .deps/orbit-interface-common.Tpo -c -o orbit-interface-common.lo orbit-interface-common.c<br>
gcc -DHAVE_CONFIG_H -I. -I../../.. -I. -I. -I../../../include -I../../../include/orbit/orb-core -I../../../include -I../../../include/orbit/orb-core -DORBIT_TYPELIB_DIR=\"/usr/local/lib/orbit-2.0\" -DORBIT2_INTERNAL_API -Wall -Wunused -Wmissing-prototypes -Wmissing-declarations -DG_DISABLE_DEPRECATED -I../../../linc2/include -I../../../linc2/include -pthread -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -g -O2 -Werror-implicit-function-declaration -MT orbit-interface-common.lo -MD -MP -MF .deps/orbit-interface-common.Tpo -c orbit-interface-common.c -fPIC -DPIC -o .libs/orbit-interface-common.o<br>
sbox-arm-linux-gcc: orbit-interface-common.c: No such file or directory<br>sbox-arm-linux-gcc: no input files<br>make[5]: *** [orbit-interface-common.lo] Error 1<br>make[5]: Leaving directory `/home/benoit/ORBit2-2.14.13/src/orb/orb-core'<br>
make[4]: *** [all] Error 2<br>make[4]: Leaving directory `/home/benoit/ORBit2-2.14.13/src/orb/orb-core'<br>make[3]: *** [all-recursive] Error 1<br>make[3]: Leaving directory `/home/benoit/ORBit2-2.14.13/src/orb'<br>
make[2]: *** [all-recursive] Error 1<br>make[2]: Leaving directory `/home/benoit/ORBit2-2.14.13/src'<br>make[1]: *** [all-recursive] Error 1<br>make[1]: Leaving directory `/home/benoit/ORBit2-2.14.13'<br>make: *** [all] Error 2<br>
<br></div>
<br />_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18527985&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18587654java client to C server on another box2008-07-17T12:24:54Z2008-07-17T12:24:54ZTom BallardI have a braindead client/server in java and another one in C using the
<br>same idl file. I haven't been able to find the proper incantation for
<br>making the java client talk to the C server. Anyone know of a simple
<br>example?
<br><br>-tom
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18587654&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18065097Re: PATCH: Fix and simplify get_netid()2008-06-23T01:52:54Z2008-06-23T01:52:54ZJules ColdingHi Michael,
<br><br>On 23/06/2008, at 10.46, Michael Meeks wrote:
<br>> Hi Jules,
<br>>
<br>> On Sat, 2008-06-21 at 21:29 +0200, Jules Colding wrote:
<br>>> The linc2/src/linc-protocols.c:get_netid() function produced nonsense
<br>>> values for ORBNetID="ipaddr" on Mac OS X Leopard. Please see:
<br>>
<br>> IPv4/6 is your baby ;-) go for it.
<br><br>Thanks :-)
<br><br><br>> OpenSolaris traditionally has
<br>> problems with changes here - but no doubt they can find those later
<br>> themselves.
<br><br>Yes, I was worrying about Solaris myself. To bad that I don't have a
<br>box to test on before making changes...
<br><br>Best regards,
<br> jules
<br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18065097&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18065034Re: PATCH: Fix and simplify get_netid()2008-06-23T01:46:01Z2008-06-23T01:46:01Zmichael meeksHi Jules,
<br><br>On Sat, 2008-06-21 at 21:29 +0200, Jules Colding wrote:
<br>> The linc2/src/linc-protocols.c:get_netid() function produced nonsense
<br>> values for ORBNetID="ipaddr" on Mac OS X Leopard. Please see:
<br><br> IPv4/6 is your baby ;-) go for it. OpenSolaris traditionally has
<br>problems with changes here - but no doubt they can find those later
<br>themselves.
<br><br> Regards,
<br><br> Michael.
<br><br>--
<br> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18065034&i=0" target="_top" rel="nofollow">michael.meeks@...</a> <><, Pseudo Engineer, itinerant idiot
<br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18065034&i=1" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18064943Re: PATCH: Fix and simplify get_netid()2008-06-23T01:41:08Z2008-06-23T01:41:08ZJules Colding<br>On 21/06/2008, at 21.29, Jules Colding wrote:
<br><div class='shrinkable-quote'><br>> Hi,
<br>>
<br>> The linc2/src/linc-protocols.c:get_netid() function produced
<br>> nonsense values for ORBNetID="ipaddr" on Mac OS X Leopard. Please see:
<br>>
<br>> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=539510" target="_top" rel="nofollow">http://bugzilla.gnome.org/show_bug.cgi?id=539510</a><br>>
<br>>
<br>> The patch below fixes this and makes for a simpler get_netid() bu
<br>> introducing a new helper function. The patch has been tested on
<br>> Leopard and Ubuntu Gutsy. "make check" is also happy on both
<br>> platforms. Please forgive me if the patch below is whitespace-messed-
<br>> up. My current mailer isn't too happy about inserted text...
<br>>
<br>> May I commit? Comments?
</div><br><br>Committed. Hopefully people will yell at me if something breaks...
<br><br><br>--
<br> jules
<br><br><br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18064943&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-18047980PATCH: Fix and simplify get_netid()2008-06-21T12:29:03Z2008-06-21T12:29:03ZJules ColdingHi,
<br><br>The linc2/src/linc-protocols.c:get_netid() function produced nonsense
<br>values for ORBNetID="ipaddr" on Mac OS X Leopard. Please see:
<br><br> <a href="http://bugzilla.gnome.org/show_bug.cgi?id=539510" target="_top" rel="nofollow">http://bugzilla.gnome.org/show_bug.cgi?id=539510</a><br><br><br>The patch below fixes this and makes for a simpler get_netid() bu
<br>introducing a new helper function. The patch has been tested on
<br>Leopard and Ubuntu Gutsy. "make check" is also happy on both
<br>platforms. Please forgive me if the patch below is whitespace-messed-
<br>up. My current mailer isn't too happy about inserted text...
<br><br>May I commit? Comments?
<br><br>Best regards,
<br> jules
<br><br><br><br><br>Index: linc2/ChangeLog
<br>===================================================================
<br>--- linc2/ChangeLog (revision 2073)
<br>+++ linc2/ChangeLog (working copy)
<br>@@ -1,3 +1,13 @@
<br>+2008-06-21 Jules Colding <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18047980&i=0" target="_top" rel="nofollow">colding@...</a>>
<br>+
<br>+ * src/linc-protocols.c (get_netid): This function
<br>+ failed on Mac OS X for (ORBNetID == "ipaddr"). It is
<br>+ now fixed and simplified greatly by the use of the new
<br>+ function get_first_non_local_ipaddr().
<br>+ (get_first_non_local_ipaddr): This function will
<br>+ correctly deduce the first non-loopback interface
<br>+ on the host.
<br>+
<br> ============================== 2.14.13 ===========================
<br><br> 2008-05-25 Tor Lillqvist <<a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18047980&i=1" target="_top" rel="nofollow">tml@...</a>>
<br>Index: linc2/src/linc-protocols.c
<br>===================================================================
<br>--- linc2/src/linc-protocols.c (revision 2073)
<br>+++ linc2/src/linc-protocols.c (working copy)
<br>@@ -145,7 +145,49 @@
<br> #endif
<br> #define DEFAULT_LINC2_IFNUM (32)
<br><br>+#ifndef G_OS_WIN32
<br> static char *
<br>+get_first_non_local_ipaddr(char *buf,
<br>+ size_t len)
<br>+{
<br>+ int sock;
<br>+ const char *retv;
<br>+ struct if_nameindex *ifname_idx_array;
<br>+ struct if_nameindex *ifname_idx;
<br>+ struct ifreq ifr;
<br>+ struct sockaddr_in sin;
<br>+
<br>+ *buf = '\0';
<br>+
<br>+ sock = socket(AF_INET, SOCK_DGRAM, 0);
<br>+ if (-1 == sock)
<br>+ return;
<br>+
<br>+ ifname_idx_array = if_nameindex();
<br>+ for (ifname_idx = ifname_idx_array; ifname_idx && ifname_idx-
<br> >if_name && ifname_idx->if_name[0]; ifname_idx++) {
<br>+ strncpy(ifr.ifr_name, ifname_idx->if_name, IFNAMSIZ);
<br>+ if (!ioctl(sock, SIOCGIFADDR, &ifr)) {
<br>+ memcpy(&sin, &(ifr.ifr_addr), sizeof(struct sockaddr_in));
<br>+ retv = (const char*)inet_ntoa(sin.sin_addr);
<br>+ retv = strcmp("127.0.0.1", retv) ? retv : NULL;
<br>+ if (retv) {
<br>+ strncpy(buf, (const char*)inet_ntoa(sin.sin_addr), len);
<br>+ break;
<br>+ }
<br>+ }
<br>+ }
<br>+
<br>+ if (ifname_idx_array)
<br>+ if_freenameindex(ifname_idx_array);
<br>+
<br>+ if (-1 != sock)
<br>+ close(sock);
<br>+
<br>+ return buf;
<br>+}
<br>+#endif
<br>+
<br>+static char *
<br> get_netid(LinkNetIdType which,
<br> char *buf,
<br> size_t len)
<br>@@ -161,58 +203,13 @@
<br> if ((LINK_NET_ID_IS_IPADDR == which)
<br> || (LINK_NET_ID_IS_CUSTOM == which)) {
<br> #ifndef G_OS_WIN32
<br>- struct sockaddr_in *adr = NULL;
<br>- struct ifreq *my_ifreqs = NULL;
<br>- struct ifconf my_ifconf = { 0 };
<br>- int sock = -1;
<br>- int num = 0;
<br>- int i = 0;
<br>+ if (fixed_host_net_id)
<br>+ strncpy(buf, fixed_host_net_id, len);
<br>+ else
<br>+ get_first_non_local_ipaddr(buf, len);
<br>+ if ('\0' == *buf)
<br>+ strncpy(buf, "127.0.0.1", len);
<br><br>- sock = socket(AF_INET,SOCK_DGRAM,0);
<br>- if (-1 == sock)
<br>- goto out;
<br>-#ifdef SIOCGIFNUM
<br>- i = ioctl(sock, SIOCGIFNUM, &num);
<br>- if ((0 > i) || !num) {
<br>- close(sock);
<br>- goto out;
<br>- }
<br>-#else
<br>- num = DEFAULT_LINC2_IFNUM;
<br>-#endif
<br>- my_ifconf.ifc_len = sizeof(struct ifreq) * num;
<br>- my_ifconf.ifc_req = (struct ifreq*)malloc(my_ifconf.ifc_len);
<br>- if (!my_ifconf.ifc_req) {
<br>- close(sock);
<br>- goto out;
<br>- }
<br>- if (ioctl(sock,SIOCGIFCONF,&my_ifconf) < 0) {
<br>- close(sock);
<br>- free(my_ifconf.ifc_req);
<br>- goto out;
<br>- }
<br>- close(sock);
<br>-
<br>- my_ifreqs = my_ifconf.ifc_req;
<br>- for (i = 0; i < num; i++) {
<br>- adr = (struct sockaddr_in *)&my_ifreqs[i].ifr_ifru.ifru_addr;
<br>- if (fixed_host_net_id) {
<br>- if (!strcmp(fixed_host_net_id, inet_ntoa(adr->sin_addr)))
<br>- break;
<br>- } else {
<br>- if (strcmp("127.0.0.1", inet_ntoa(adr->sin_addr)))
<br>- break;
<br>- }
<br>- if (!strcmp("0.0.0.0", inet_ntoa(adr->sin_addr))) {
<br>- if (i)
<br>- adr = (struct sockaddr_in *)&my_ifreqs[--i].ifr_ifru.ifru_addr;
<br>- break;
<br>- }
<br>- }
<br>- strncpy(buf, (const char*)inet_ntoa(adr->sin_addr), len);
<br>- free(my_ifconf.ifc_req);
<br>-
<br>- /* will be 127.0.0.1 anyway, if no other address is defined... */
<br> return buf;
<br> #else
<br> SOCKET sock;
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=18047980&i=2" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17359886Lorica - A CORBA firewall conduit2008-05-21T03:00:05Z2008-05-21T03:00:05ZJules ColdingHi all,
<br><br>I just want briefly to mention that Lorica 1.0 is released. Lorica
<br>solves the CORBA firewall problem by tunneling all CORBA connections
<br>through one specific network port. It is GPL'ed and available from
<br><lorica.42tools.com>. Binaries exists for Fedora 8, Gentoo, RHEL4u4,
<br>Mac OS X, Ubuntu Gutsy and Windows.
<br><br>Best regards,
<br> jules
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17359886&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17317193RE: Making ORBit work with MS VS compilers2008-05-16T04:26:29Z2008-05-16T04:26:29ZMarkus Duft<div class='shrinkable-quote'>>
<br>> > Attached is our patch for ORBit2-2.14.2, which also fixes the idl
<br>> > compiler to create code that can be built into a Windows dll.
<br>>
<br>> Sorry for taking so long to get back to this issue... I haven't really
<br>> done anything about this in the meantime. I had a look at this patch
<br>> now.
<br>>
<br>> The patch changes this in Makefile.shared:
<br>>
<br>> - $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<
<br>> + if test `uname` = "Interix" ; then \
<br>> + $(IDL_COMPILER) $(IDL_FLAGS_W32) --deps
</div>$(*D)/.deps/$(*F).idl.P
<br>> `unixpath2win $<`; \
<br>> + else \
<br>> + $(IDL_COMPILER) $(IDL_FLAGS) --deps
<br>$(*D)/.deps/$(*F).idl.P $<; \
<br>> + fi
<br>>
<br>> Surely this approach can't be feasible in the long run? If the
<br>> eventual goal is for instance to make those modules in the GNOME stack
<br>> that currently can be built for Win32 with mingw on msys also
<br>> buildable with parity on Interix, aren't there hundreds of Makefiles
<br>> and other places where similar stuff would need to be changed then?
<br>> Ditto for the other parts in the diff where unixpath2win is involved.
<br><br>First of all Hi :)
<br><br>Parity got better in the meantime, and any binary that is built with
<br>parity understands all kinds of paths, also interix ones. So the
<br>unixpath2win can be omitted if $IDL_COMPILER points to a binary that was
<br>built with parity (which should be the case anyway)
<br><br>>
<br>> Is it possible to use "mounts" like MSYS in Interix? I.e., is it
<br>> possible to make an Interix "Unix" path like /foo/bar refer to the
<br>> same actual location as the Win32 path X:\foo\bar? (Where X: is the
<br>> drive you are doing the work on, hopefully you don't have to use
<br>> several drive letters) Then one could simply require that such mounts
<br>> are used and no unixpath2win invocations would be needed to be added
<br>> all over the place.
<br><br>On interix /dev/fs/C maps to C:. there is no other means of mounting
<br>anything.... but the whole last paragraph is obsolete because as I said
<br>already, parity built binaries can handle both styles of paths, even if
<br>you mix them (only exception: in a path list (separated by : on interix,
<br>and ; on windows) all paths must be the same style (either windows or
<br>unix) or otherwise the path conversion routines will get confused...)
<br><br>>
<br>> I think at least currently Interix is not really that popular among
<br>> people porting software from Unix to Windows. I don't feel it would be
<br>> worth it at this point at least to apply your patch to the sources,
<br>> sorry.
<br><br>Hmm... yeah, but interix _will_ get popular I think/hope/believe, since
<br>I made a port of Gentoo Prefix to interix, which enables even the use of
<br>gnome-terminal. From there onwards I'm just working on being able to
<br>build native windows binaries too, which would make things really cool
<br>:)
<br><br>Cheers, Markus
<br><br>>
<br>> --tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17317193&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17270667Re: Making ORBit work with MS VS compilers2008-05-16T02:18:29Z2008-05-16T02:18:29ZTor Lillqvist> Attached is our patch for ORBit2-2.14.2, which also fixes the idl
<br>> compiler to create code that can be built into a Windows dll.
<br><br>Sorry for taking so long to get back to this issue... I haven't really
<br>done anything about this in the meantime. I had a look at this patch
<br>now.
<br><br>The patch changes this in Makefile.shared:
<br><br>- $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<
<br>+ if test `uname` = "Interix" ; then \
<br>+ $(IDL_COMPILER) $(IDL_FLAGS_W32) --deps $(*D)/.deps/$(*F).idl.P
<br>`unixpath2win $<`; \
<br>+ else \
<br>+ $(IDL_COMPILER) $(IDL_FLAGS) --deps $(*D)/.deps/$(*F).idl.P $<; \
<br>+ fi
<br><br>Surely this approach can't be feasible in the long run? If the
<br>eventual goal is for instance to make those modules in the GNOME stack
<br>that currently can be built for Win32 with mingw on msys also
<br>buildable with parity on Interix, aren't there hundreds of Makefiles
<br>and other places where similar stuff would need to be changed then?
<br>Ditto for the other parts in the diff where unixpath2win is involved.
<br><br>Is it possible to use "mounts" like MSYS in Interix? I.e., is it
<br>possible to make an Interix "Unix" path like /foo/bar refer to the
<br>same actual location as the Win32 path X:\foo\bar? (Where X: is the
<br>drive you are doing the work on, hopefully you don't have to use
<br>several drive letters) Then one could simply require that such mounts
<br>are used and no unixpath2win invocations would be needed to be added
<br>all over the place.
<br><br>I think at least currently Interix is not really that popular among
<br>people porting software from Unix to Windows. I don't feel it would be
<br>worth it at this point at least to apply your patch to the sources,
<br>sorry.
<br><br>--tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17270667&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17150318Re: Problem with the timeout code2008-05-09T08:17:50Z2008-05-09T08:17:50ZJules Colding<br>On 09/05/2008, at 16.37, Michael Meeks wrote:
<br><div class='shrinkable-quote'><br>>
<br>> On Fri, 2008-05-09 at 11:27 +0200, Jules Colding wrote:
<br>>>> - Make sure giop_thread_free() is not called on threads associated
<br>>>> with connections for which timeouts are outstanding. Is this
<br>>>> feasible?
<br>>>> It sounds kinda like a clean and obvious solution, but I don't
<br>>>> really
<br>>>> understand the code that well...
<br>>>>
<br>>>> Jules, do you have any ideas? Have you ever seen this happen?
<br>>>
<br>>> I've never seen this happen before. I would agree that your proposal
<br>>> number 3 is the way to go, but I can not clearly see how to implement
<br>>> it. Michael?
<br>>
<br>> Really, it's not that clear to me how we are doing a thread_free and
<br>> the continuing to wait for a timeout in that thread ;-)
<br>>
<br>> Are we correctly de-registering the timeout after we finish waiting ?
</div><br>I certainly think we are. I may have made an error but I was careful
<br>to ref/unref whenever appropriate.
<br><br>BR,
<br> jules
<br><br><br><div class='shrinkable-quote'><br>>
<br>> or does the timeout get triggered in the IO thread or something ? :-)
<br>>
<br>> Regards,
<br>>
<br>> Michael.
<br>>
<br>> --
<br>> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17150318&i=0" target="_top" rel="nofollow">michael.meeks@...</a> <><, Pseudo Engineer, itinerant idiot
<br>>
<br>>
</div><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17150318&i=1" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17149482Re: Problem with the timeout code2008-05-09T07:37:44Z2008-05-09T07:37:44Zmichael meeks<br>On Fri, 2008-05-09 at 11:27 +0200, Jules Colding wrote:
<div class='shrinkable-quote'><br>> > - Make sure giop_thread_free() is not called on threads associated
<br>> > with connections for which timeouts are outstanding. Is this feasible?
<br>> > It sounds kinda like a clean and obvious solution, but I don't really
<br>> > understand the code that well...
<br>> >
<br>> > Jules, do you have any ideas? Have you ever seen this happen?
<br>>
<br>> I've never seen this happen before. I would agree that your proposal
<br>> number 3 is the way to go, but I can not clearly see how to implement
<br>> it. Michael?
</div><br> Really, it's not that clear to me how we are doing a thread_free and
<br>the continuing to wait for a timeout in that thread ;-)
<br><br> Are we correctly de-registering the timeout after we finish waiting ?
<br>or does the timeout get triggered in the IO thread or something ? :-)
<br><br> Regards,
<br><br> Michael.
<br><br>--
<br> <a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17149482&i=0" target="_top" rel="nofollow">michael.meeks@...</a> <><, Pseudo Engineer, itinerant idiot
<br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17149482&i=1" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17144434Re: Problem with the timeout code2008-05-09T02:27:21Z2008-05-09T02:27:21ZJules ColdingHi Tor,
<br><br>On 08/05/2008, at 17.15, Tor Lillqvist wrote:
<br><div class='shrinkable-quote'><br>> I have run across a repeatable crash in a program that uses ORBit2 on
<br>> Windows. The crash is caused by code for the relatively new timeout
<br>> functionality added by Jules Colding. For some reason I see this crash
<br>> only in this one specific program (that I just recently started
<br>> testing on Windows), not in other programs that also use ORBit2
<br>> heavily.
<br>>
<br>> In a nutshell, the problem is that giop_thread_free() frees a
<br>> GIOPThread while there still is an outstanding timeout added with
<br>> giop_timeout_add() for a connection whose thread is that thread. This
<br>> leads to heap corruption (references to freed memory).
<br>>
<br>> I added some debugging printouts to the linc2 and GIOP code. Here is
<br>> an annotated dump of the output:
<br>>
<br>> First just some introductory logging. As you see the debugging output
<br>> I added prints GIOPConnection (== a LinkConnection subclass) struct
<br>> pointers, reference counts of it, and the tdata (GIOPThread*) pointer
<br>> of the LinkConnection.
<br>>
<br>> link_connection_ref_T: cnx=062FB320 ref_count=1 tdata=00000000
<br>> link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>> link_connection_ref_T: cnx=062FB320 ref_count=2 tdata=00000000
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=2 tdata=00000000
<br>> link_connection_init: cnx=062FB370
<br>> link_connection_ref_T: cnx=062FB370 ref_count=1 tdata=00000000
<br>> link_connection_ref: cnx=062FB370 ref_count=2 tdata=00000000
<br>> link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=00000000
<br>> link_connection_ref: cnx=062FB370 ref_count=2 tdata=00000000
<br>>
<br>> Here giop_timeout_add() is called for a GIOPConnection:
<br>>
<br>> giop_timeout_add:1432: lcnx=062FB370 tdata=06334710 tdata-
<br>> >lock=06335A88
<br>>
<br>> link_connection_ref_T: cnx=062FB370 ref_count=3 tdata=06334710
<br>> link_connection_unref_unlock: cnx=062FB370 ref_count=4 tdata=06334710
<br>> link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=06334710
<br>>
<br>> Now comes the interesting parts. giop_thread_free() gets called for
<br>> the tdata of the GIOPConnection that was passed to giop_timeout_add()
<br>> above.
<br>>
<br>> giop_thread_free:343: tdata=06334710 tdata->lock=06335A88
<br>> giop_thread_free:350: tdata=06334710 tdata->lock=00000000
<br>> giop_thread_free:363: FREEING tdata=06334710
<br>>
<br>> Other stuff...
<br>>
<br>> link_connection_ref_T: cnx=062FB320 ref_count=1 tdata=00000000
<br>> link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>> link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>> giop_timeout_add:1432: lcnx=062FB320 tdata=06335910 tdata-
<br>> >lock=06335A88
<br>> link_connection_ref_T: cnx=062FB320 ref_count=3 tdata=06335910
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=4 tdata=06335910
<br>> link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=06335910
<br>> giop_thread_free:343: tdata=06335910 tdata->lock=06335A88
<br>> giop_thread_free:350: tdata=06335910 tdata->lock=00000000
<br>> giop_thread_free:363: FREEING tdata=06335910
<br>>
<br>> Now then the timeout fires for connection 062FB370. The tdata pointer
<br>> that gets passed to giop_timeout() is the one that was freed in the
<br>> first giop_thread_free() above. So giop_timeout() is using freed
<br>> memory here. This obviously causes problems sooner or later. (Without
<br>> changes to the code, the memory happens to still be intact, and the
<br>> crash comes from the tdata->lock pointer still being NULL after
<br>> giop_thread_free() set it so.)
<br>>
<br>> giop_timeout:1373: cnx=062FB370 tdata=06334710 tdata->lock=00000000
<br>> link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=06334710
<br>> giop_timeout:1394: cnx=062FB370 tdata=06334710 tdata->lock=00000000
<br>>
<br>> And then *crash* when g_mutex_lock() is called on the NULL pointer.
<br>>
<br>> How to solve this? I can think of some alternative approaches:
<br>>
<br>> - Keep a "back" pointer to the LinkConnection in the GIOPThread
<br>> struct. When setting up a timeout for the connection, initialise this
<br>> pointer. When freeing the thread before the timeout has expired, set
<br>> the tdata pointer of the corresponding connection to NULL. Michael
<br>> Meeks says this is ugly as it adds coupling between relatively
<br>> unconnected concepts. And can we be sure that each thread has just one
<br>> connection, no idea...
<br>>
<br>> - Make sure the timeout is always zero for local connections? The
<br>> rationale for the timeout code in Jules's ChangeLog entry from
<br>> 2006-12-05 talks about timeouts being necessary for remote servers
<br>> only. In my case, the connection is a local one (using TCP, though, no
<br>> Unix domain sockers on Windows obviously). This would probably solve
<br>> the problem I see. But can we be sure that this problematic scenario
<br>> can never happen for remote connections?
<br>>
<br>> - Make sure giop_thread_free() is not called on threads associated
<br>> with connections for which timeouts are outstanding. Is this feasible?
<br>> It sounds kinda like a clean and obvious solution, but I don't really
<br>> understand the code that well...
<br>>
<br>> Jules, do you have any ideas? Have you ever seen this happen?
</div><br>I've never seen this happen before. I would agree that your proposal
<br>number 3 is the way to go, but I can not clearly see how to implement
<br>it. Michael?
<br><br>Best regards,
<br> jules
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17144434&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-17129861Problem with the timeout code2008-05-08T08:15:43Z2008-05-08T08:15:43ZTor LillqvistI have run across a repeatable crash in a program that uses ORBit2 on
<br>Windows. The crash is caused by code for the relatively new timeout
<br>functionality added by Jules Colding. For some reason I see this crash
<br>only in this one specific program (that I just recently started
<br>testing on Windows), not in other programs that also use ORBit2
<br>heavily.
<br><br>In a nutshell, the problem is that giop_thread_free() frees a
<br>GIOPThread while there still is an outstanding timeout added with
<br>giop_timeout_add() for a connection whose thread is that thread. This
<br>leads to heap corruption (references to freed memory).
<br><br>I added some debugging printouts to the linc2 and GIOP code. Here is
<br>an annotated dump of the output:
<br><br>First just some introductory logging. As you see the debugging output
<br>I added prints GIOPConnection (== a LinkConnection subclass) struct
<br>pointers, reference counts of it, and the tdata (GIOPThread*) pointer
<br>of the LinkConnection.
<br><br>link_connection_ref_T: cnx=062FB320 ref_count=1 tdata=00000000
<br>link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>link_connection_ref_T: cnx=062FB320 ref_count=2 tdata=00000000
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=2 tdata=00000000
<br>link_connection_init: cnx=062FB370
<br>link_connection_ref_T: cnx=062FB370 ref_count=1 tdata=00000000
<br>link_connection_ref: cnx=062FB370 ref_count=2 tdata=00000000
<br>link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=00000000
<br>link_connection_ref: cnx=062FB370 ref_count=2 tdata=00000000
<br><br>Here giop_timeout_add() is called for a GIOPConnection:
<br><br>giop_timeout_add:1432: lcnx=062FB370 tdata=06334710 tdata->lock=06335A88
<br><br>link_connection_ref_T: cnx=062FB370 ref_count=3 tdata=06334710
<br>link_connection_unref_unlock: cnx=062FB370 ref_count=4 tdata=06334710
<br>link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=06334710
<br><br>Now comes the interesting parts. giop_thread_free() gets called for
<br>the tdata of the GIOPConnection that was passed to giop_timeout_add()
<br>above.
<br><br>giop_thread_free:343: tdata=06334710 tdata->lock=06335A88
<br>giop_thread_free:350: tdata=06334710 tdata->lock=00000000
<br>giop_thread_free:363: FREEING tdata=06334710
<br><br>Other stuff...
<br><br>link_connection_ref_T: cnx=062FB320 ref_count=1 tdata=00000000
<br>link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=00000000
<br>link_connection_ref: cnx=062FB320 ref_count=2 tdata=00000000
<br>giop_timeout_add:1432: lcnx=062FB320 tdata=06335910 tdata->lock=06335A88
<br>link_connection_ref_T: cnx=062FB320 ref_count=3 tdata=06335910
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=4 tdata=06335910
<br>link_connection_unref_unlock: cnx=062FB320 ref_count=3 tdata=06335910
<br>giop_thread_free:343: tdata=06335910 tdata->lock=06335A88
<br>giop_thread_free:350: tdata=06335910 tdata->lock=00000000
<br>giop_thread_free:363: FREEING tdata=06335910
<br><br>Now then the timeout fires for connection 062FB370. The tdata pointer
<br>that gets passed to giop_timeout() is the one that was freed in the
<br>first giop_thread_free() above. So giop_timeout() is using freed
<br>memory here. This obviously causes problems sooner or later. (Without
<br>changes to the code, the memory happens to still be intact, and the
<br>crash comes from the tdata->lock pointer still being NULL after
<br>giop_thread_free() set it so.)
<br><br>giop_timeout:1373: cnx=062FB370 tdata=06334710 tdata->lock=00000000
<br>link_connection_unref_unlock: cnx=062FB370 ref_count=3 tdata=06334710
<br>giop_timeout:1394: cnx=062FB370 tdata=06334710 tdata->lock=00000000
<br><br>And then *crash* when g_mutex_lock() is called on the NULL pointer.
<br><br>How to solve this? I can think of some alternative approaches:
<br><br>- Keep a "back" pointer to the LinkConnection in the GIOPThread
<br>struct. When setting up a timeout for the connection, initialise this
<br>pointer. When freeing the thread before the timeout has expired, set
<br>the tdata pointer of the corresponding connection to NULL. Michael
<br>Meeks says this is ugly as it adds coupling between relatively
<br>unconnected concepts. And can we be sure that each thread has just one
<br>connection, no idea...
<br><br>- Make sure the timeout is always zero for local connections? The
<br>rationale for the timeout code in Jules's ChangeLog entry from
<br>2006-12-05 talks about timeouts being necessary for remote servers
<br>only. In my case, the connection is a local one (using TCP, though, no
<br>Unix domain sockers on Windows obviously). This would probably solve
<br>the problem I see. But can we be sure that this problematic scenario
<br>can never happen for remote connections?
<br><br>- Make sure giop_thread_free() is not called on threads associated
<br>with connections for which timeouts are outstanding. Is this feasible?
<br>It sounds kinda like a clean and obvious solution, but I don't really
<br>understand the code that well...
<br><br>Jules, do you have any ideas? Have you ever seen this happen?
<br><br>(If somebody wants to run tests with the same debugging output, I can
<br>mail the svn diff.)
<br><br>--tml
<br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=17129861&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-16901111Re: SEGV in current svn trunk2008-04-25T09:41:23Z2008-04-25T09:41:23ZJules Colding<br>On 25/04/2008, at 10.02, Jules Colding wrote:
<br><div class='shrinkable-quote'><br>>
<br>> On 25/04/2008, at 09.21, Tor Lillqvist wrote:
<br>>
<br>>>> I'm getting segmentation faults repeatedly on Ubuntu Gutsy with my
<br>>>> small ORBit2 (svn trunk) based daemon.
<br>>>
<br>>> When did you start getting the segfaults? Was it after my commit to
<br>>> linc2/src/linc.c on 2008-04-23? If so that change will have to be
<br>>> reverted. Or correspondingly, if it was after some other recent
<br>>> change, you need to check if reverting that change helps. There
<br>>> hasn't
<br>>> really been much done to ORBit2 lately, so if your code used to work
<br>>> fine earlier, finding what broke it shouldn't be hard.
<br>>
<br>>
<br>> I saw the segfault for the first time yesterday. Fortunately I hope it
<br>> is due to a mix-up of libraries from 2.14.9 and 2.14.<svn trunk>. This
<br>> morning I discovered that I had old libraries lying around which I've
<br>> now cleaned up. I strongly suspect this to be the real reason as your
<br>> fixes looks really innocent. I'll make some further testing to confirm
<br>> it and will let you know later today.
</div><br>No segfaults yet. I think we can safely conclude that the library mess
<br>was the culprit.
<br><br>Best regards,
<br> jules
<br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=16901111&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>tag:www.nabble.com,2006:post-16892599Re: SEGV in current svn trunk2008-04-25T01:02:15Z2008-04-25T01:02:15ZJules Colding<br>On 25/04/2008, at 09.21, Tor Lillqvist wrote:
<br><br>>> I'm getting segmentation faults repeatedly on Ubuntu Gutsy with my
<br>>> small ORBit2 (svn trunk) based daemon.
<br>>
<br>> When did you start getting the segfaults? Was it after my commit to
<br>> linc2/src/linc.c on 2008-04-23? If so that change will have to be
<br>> reverted. Or correspondingly, if it was after some other recent
<br>> change, you need to check if reverting that change helps. There hasn't
<br>> really been much done to ORBit2 lately, so if your code used to work
<br>> fine earlier, finding what broke it shouldn't be hard.
<br><br><br>I saw the segfault for the first time yesterday. Fortunately I hope it
<br>is due to a mix-up of libraries from 2.14.9 and 2.14.<svn trunk>. This
<br>morning I discovered that I had old libraries lying around which I've
<br>now cleaned up. I strongly suspect this to be the real reason as your
<br>fixes looks really innocent. I'll make some further testing to confirm
<br>it and will let you know later today.
<br><br><br>Best regards,
<br> jules
<br><br><br><br>_______________________________________________
<br>orbit-list mailing list
<br><a href="http://www.nabble.com/user/SendEmail.jtp?type=post&post=16892599&i=0" target="_top" rel="nofollow">orbit-list@...</a>
<br><a href="http://mail.gnome.org/mailman/listinfo/orbit-list" target="_top" rel="nofollow">http://mail.gnome.org/mailman/listinfo/orbit-list</a><br><p>From forum: <a href="http://www.nabble.com/Gnome---ORBit---General-f1387.html" embed="fixTarget[1387]" target="_top" >Gnome - ORBit - General</a></p>