orbitcpp-list Mailing List for orbitcpp (Page 18)
Status: Beta
Brought to you by:
philipd
Menu
▾
▴
orbitcpp-list
You can subscribe to this list here.
| 1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(7) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2000 |
Jan
(19) |
Feb
(45) |
Mar
(53) |
Apr
(64) |
May
(22) |
Jun
(6) |
Jul
(56) |
Aug
(11) |
Sep
(32) |
Oct
(27) |
Nov
(43) |
Dec
(25) |
| 2001 |
Jan
(11) |
Feb
(26) |
Mar
(16) |
Apr
(19) |
May
(19) |
Jun
(28) |
Jul
(16) |
Aug
(12) |
Sep
(7) |
Oct
(9) |
Nov
(1) |
Dec
(35) |
| 2002 |
Jan
(45) |
Feb
(66) |
Mar
(25) |
Apr
(20) |
May
(15) |
Jun
(1) |
Jul
(1) |
Aug
(3) |
Sep
(7) |
Oct
|
Nov
(2) |
Dec
(26) |
| 2003 |
Jan
(8) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
(2) |
Jul
(2) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2006 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(2) |
Jul
(4) |
Aug
(4) |
Sep
(4) |
Oct
(17) |
Nov
(23) |
Dec
(5) |
| 2007 |
Jan
(37) |
Feb
(20) |
Mar
(16) |
Apr
(23) |
May
(20) |
Jun
(12) |
Jul
(20) |
Aug
(25) |
Sep
(15) |
Oct
(8) |
Nov
(5) |
Dec
(3) |
| 2008 |
Jan
(9) |
Feb
(6) |
Mar
(37) |
Apr
(28) |
May
(12) |
Jun
(9) |
Jul
(30) |
Aug
(7) |
Sep
(20) |
Oct
(26) |
Nov
(50) |
Dec
(75) |
| 2009 |
Jan
(63) |
Feb
(46) |
Mar
(54) |
Apr
(53) |
May
(125) |
Jun
(102) |
Jul
(90) |
Aug
(46) |
Sep
(26) |
Oct
(32) |
Nov
(9) |
Dec
(29) |
| 2010 |
Jan
(9) |
Feb
(8) |
Mar
(45) |
Apr
(56) |
May
(74) |
Jun
(73) |
Jul
(34) |
Aug
(48) |
Sep
(23) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2011 |
Jan
(5) |
Feb
(3) |
Mar
(17) |
Apr
(3) |
May
(2) |
Jun
(3) |
Jul
(4) |
Aug
(8) |
Sep
(17) |
Oct
(6) |
Nov
(5) |
Dec
(10) |
| 2012 |
Jan
(3) |
Feb
(15) |
Mar
(4) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
(5) |
Aug
(3) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2013 |
Jan
(2) |
Feb
(3) |
Mar
(1) |
Apr
(4) |
May
(4) |
Jun
(3) |
Jul
(6) |
Aug
(52) |
Sep
(3) |
Oct
(5) |
Nov
(1) |
Dec
(8) |
| 2014 |
Jan
(1) |
Feb
(16) |
Mar
(9) |
Apr
(11) |
May
(16) |
Jun
(15) |
Jul
(13) |
Aug
(4) |
Sep
(2) |
Oct
(3) |
Nov
|
Dec
(3) |
| 2015 |
Jan
(5) |
Feb
(1) |
Mar
(5) |
Apr
(1) |
May
(5) |
Jun
(3) |
Jul
(4) |
Aug
(2) |
Sep
(1) |
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(3) |
Dec
(1) |
| 2017 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
(5) |
May
(1) |
Jun
(2) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: <no...@so...> - 2002-01-02 04:28:12
|
Patches item #497705, was opened at 2001-12-29 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=497705&group_id=646 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Braden McDaniel (braden) >Assigned to: Sam Couter (eddiesam) Summary: Don't overwrite user variables in build Initial Comment: The thrust of this patch is to fix the places that variables like CFLAGS and CXXFLAGS were set in the Makefile.am's. These are variables that can be set by the user at configure time. Also fixed in this patch: compiler/Makefile.am had headers listed in a _SOURCES variable. These entries more properly belong in a noinst_HEADERS variable. This patch obsoletes the file Makefile.buildvars. ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2002-01-01 20:28 Message: Logged In: YES user_id=14486 Patch committed to CVS. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=497705&group_id=646 |
|
From: <no...@so...> - 2001-12-29 22:36:54
|
Patches item #497705, was opened at 2001-12-29 14:36 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=497705&group_id=646 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Braden McDaniel (braden) Assigned to: Nobody/Anonymous (nobody) Summary: Don't overwrite user variables in build Initial Comment: The thrust of this patch is to fix the places that variables like CFLAGS and CXXFLAGS were set in the Makefile.am's. These are variables that can be set by the user at configure time. Also fixed in this patch: compiler/Makefile.am had headers listed in a _SOURCES variable. These entries more properly belong in a noinst_HEADERS variable. This patch obsoletes the file Makefile.buildvars. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=497705&group_id=646 |
|
From: Sam C. <sa...@to...> - 2001-12-20 23:37:54
|
R.M.Morrien <rm....@qu...> wrote: >=20 > I need a simple HelloWorld example with a simple Makefile.. is there one?= I > can't seem to find one.. Everyone on the list may be interested in this: I found the orbitcpp-examples tarball lying around on my hard drive. I think it's the code that used to be available via FTP from SourceForge. I've uploaded it to SourceForge, so people can download it from the Downloads page. It contains a very simple Hello World example, a Hello World example which uses the ORBit Naming Service, and a simple object factory example. I think I'll import it into CVS as well. --=20 Sam Couter | Internet Engineer | http://www.topic.com.au/ sa...@to... | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C |
|
From: R.M.Morrien <rm....@qu...> - 2001-12-18 14:38:20
|
Hi I installed Orbitcpp version 0.30 succesfully under RedHat7.2 with = ORBit 5.8-4 rpm. I tried the test directory and make works and the test client en server = program run. BUT... it's to hard to start with..=20 I need a simple HelloWorld example with a simple Makefile.. is there = one? I can't seem to find one.. I found something in a german news group.. but I couldn't get it to work If someone could send me a simple HelloWorld example that like the test = writes the IOR to a file which the client reads. I would love to write a = helloWorld howto for ORBitcpp ....=20 How did you start your first application with Orbitcpp ?? Martijn Morrien rm....@qu... |
|
From: Sam C. <sa...@to...> - 2001-12-11 05:13:47
|
Braden McDaniel <br...@en...> wrote: > Yes, but now I'm afraid I'll have to put you off for a few weeks. :-) Hehehe... Serves me right. :) > Yep. I actually went ahead and did this. It works well. When I get a > chance, it shouldn't take me too long to get the patch together. Excellent. > I'd be happy to... But it'll probably have to wait until I've moved into > a new apartment. :-) No problem. --=20 Sam Couter | Internet Engineer | http://www.topic.com.au/ sa...@to... | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C |
|
From: Braden M. <br...@en...> - 2001-12-11 05:10:53
|
On Sat, 2001-12-08 at 01:15, Sam Couter wrote: > Braden, > > It's been a while since we last discussed ORBit-C++. Are you still > interested in helping out? I have more time to work on it now. Yes, but now I'm afraid I'll have to put you off for a few weeks. :-) I've just relocated from Miami to Washington, DC, and things are a bit hectic. > Braden McDaniel <br...@en...> wrote: > > The reason this would be necessary is that libtool doesn't provide a > > means to selectively build shared/static libs on a per-library basis. > > This selection is done per configure script. > > I've thought about this a bit, and I now agree that a seperate configure > script for the orbit-idl compiler plugin would be useful. > > The main reason I didn't want one before is additional complexity, but I > see it as necessary now. > > There is also a second problem which it would allow us to solve: The > compiler plugin library should be a .so file with no versioning and no > symlinks, and the soname should match the filename. Yep. I actually went ahead and did this. It works well. When I get a chance, it shouldn't take me too long to get the patch together. > I've merged your other patches (RPM spec file, "make distclean" fix) > into the CVS repository. Feel free to send more for building the compiler > component with a seperate configure script, the other build problems > you've mentioned, or anything else you have fixed. I'd be happy to... But it'll probably have to wait until I've moved into a new apartment. :-) Braden |
|
From: <no...@so...> - 2001-12-09 23:11:01
|
Bugs item #475580, was opened at 2001-10-27 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francesco Lamonica (franci) Assigned to: Sam Couter (eddiesam) Summary: Compilation fail Initial Comment: Compilation fails on the test suite (at least in slackware 7.x and 8). This is due to the static linking against the glib.a libraray... maybe the compiler (gcc 2.95.3) should be explicitly told that is a static lib (static linking has always been a little annoying). Btw adding the -lglib flags made the compilation go smoothlessly ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-09 15:10 Message: Logged In: YES user_id=14486 I think this bug is just a symptom, and the real problem is that the tests are linking statically. If the tests are modified to link dynamically instead, this bug should go away. ---------------------------------------------------------------------- Comment By: Francesco Lamonica (franci) Date: 2001-12-08 04:44 Message: Logged In: YES user_id=1349 in the test suite the command line tell compiler to just use the glib.a file that would cos the linker to got nut and do not work properly.... instead of using the glib.a file using the shared library causes no problem at all. So i think that the linker is always checking for the shared library and that should be taold explicitly to usa static linking.... maybe with the -Wl,static flag but i am not sure about the correct syntax.... ---------------------------------------------------------------------- Comment By: Sam Couter (eddiesam) Date: 2001-12-07 22:49 Message: Logged In: YES user_id=14486 Francesco: Can you provide more information on this? Can you explain how the static linking causes problems? I don't have any problems, using gcc 2.95.4 20011006. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 |
|
From: <bb...@ya...> - 2001-12-09 21:41:43
|
If there is serious interest (ORBit-2) that is going to bring new development to this project then it is probably important that things are properly documented. This would reduce the initial learning overhead of new developers joining the effort. I started investigating inserting doxygen (javaDoc-style) doc blocks into ORBitcpp code a while ago. Doxygen (at www.doxygen.org), if you haven't used it, is an excellent and very flexible code documentation tool. I'm in the process of putting together general comment block templates for functions, classes, files etc. If this would be useful to anyone at this point let me know and I'll make an effort to get something out there soon - and send patches for some of the doc I've been working on. -- Rich http://shopping.yahoo.com.au - Yahoo! Shopping - Free CDs for thousands of Priority Shoppers! |
|
From: <no...@so...> - 2001-12-08 12:44:43
|
Bugs item #475580, was opened at 2001-10-27 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francesco Lamonica (franci) Assigned to: Sam Couter (eddiesam) Summary: Compilation fail Initial Comment: Compilation fails on the test suite (at least in slackware 7.x and 8). This is due to the static linking against the glib.a libraray... maybe the compiler (gcc 2.95.3) should be explicitly told that is a static lib (static linking has always been a little annoying). Btw adding the -lglib flags made the compilation go smoothlessly ---------------------------------------------------------------------- >Comment By: Francesco Lamonica (franci) Date: 2001-12-08 04:44 Message: Logged In: YES user_id=1349 in the test suite the command line tell compiler to just use the glib.a file that would cos the linker to got nut and do not work properly.... instead of using the glib.a file using the shared library causes no problem at all. So i think that the linker is always checking for the shared library and that should be taold explicitly to usa static linking.... maybe with the -Wl,static flag but i am not sure about the correct syntax.... ---------------------------------------------------------------------- Comment By: Sam Couter (eddiesam) Date: 2001-12-07 22:49 Message: Logged In: YES user_id=14486 Francesco: Can you provide more information on this? Can you explain how the static linking causes problems? I don't have any problems, using gcc 2.95.4 20011006. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 |
|
From: <no...@so...> - 2001-12-08 07:08:23
|
Support Requests item #447061, was opened at 2001-08-01 23:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=447061&group_id=646 Category: None Group: None Status: Open Priority: 5 Submitted By: Max Lybbert (mlybbert) >Assigned to: Sam Couter (eddiesam) Summary: gcc reports 4 arrays too long Initial Comment: I keep getting reports that some arrays in $PATH/path/test/eveything/generated are too long, namely: test_LongArray test_StrArray test_StrArrayMultiDimensional test_StrArrayMultiDimensional_slice What is the limit under gcc on a 32-bit machine (Intel)? Can I safely adjust the size of these arrays without worrying about trouble later? What program generated them, and what is their size supposed to be dependent on? Yes, I could figure this out by reading the source, but I'm a new programmer and I really don't trust myself here. Especially in a header file. ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-07 23:08 Message: Logged In: YES user_id=14486 Those files are generated by the IDL compiler. Don't modify them. Their size is supposed to be defined in the IDL. Eg, test_LongArray is supposed to be length 2. If any other size appears, it would be a bug in the IDL compiler backend. Does this problem still occur with ORBit-C++ 0.30.2? If so, what version of ORBit do you have installed? ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=447061&group_id=646 |
|
From: <no...@so...> - 2001-12-08 07:05:11
|
Support Requests item #452143, was opened at 2001-08-17 09:23 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=452143&group_id=646 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Sam Couter (eddiesam) Summary: Error while compiling Initial Comment: The configure script works perfectly but I 've an error while compiling. I use Suse 7.2 and I've installed the orbit and orbit-devel packages from the distrib. It seems that my version of orbit is 0.5.7 Here is what returned make: Making all in compiler make[1]: Entering directory `/var/tmp/orbitcpp- 0.30.1/compiler' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/compiler' Making all in orb make[1]: Entering directory `/var/tmp/orbitcpp- 0.30.1/orb' make[1]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/orb' Making all in services make[1]: Entering directory `/var/tmp/orbitcpp- 0.30.1/services' Making all in name make[2]: Entering directory `/var/tmp/orbitcpp- 0.30.1/services/name' make[2]: Nothing to be done for `all'. make[2]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/services/name' make[2]: Entering directory `/var/tmp/orbitcpp- 0.30.1/services' make[2]: Nothing to be done for `all-am'. make[2]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/services' make[1]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/services' Making all in test make[1]: Entering directory `/var/tmp/orbitcpp- 0.30.1/test' Making all in everything make[2]: Entering directory `/var/tmp/orbitcpp- 0.30.1/test/everything' Making all in generated make[3]: Entering directory `/var/tmp/orbitcpp- 0.30.1/test/everything/generated' gcc -DHAVE_CONFIG_H -I. -I. -I../../../orb -I../../.. - I../../.. -I/usr/include/glib-1.2 - I/usr/lib/glib/include -I/usr/include -g -O0 - Wall -W -c everything-common.c make[3]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/test/everything/generated' make[2]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/test/everything' make[1]: Leaving directory `/var/tmp/orbitcpp- 0.30.1/test' everything-common.c:622: `TC_CORBA_sequence_CORBA_any_struct' undeclared here (not in a function) everything-common.c:622: initializer element is not constant everything-common.c:622: (near initialization for `anon_subtypes_array128[0]') everything-common.c: In function `test_FixedLengthStruct__free': everything-common.c:2616: warning: unused parameter `dat' everything-common.c:2617: warning: unused parameter `free_strings' everything-common.c: In function `test_VariableLengthStruct__free': everything-common.c:2637: warning: unused parameter `dat' everything-common.c: In function `test_CompoundStruct__free': everything-common.c:2662: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_CORBA_string__free': everything-common.c:2702: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_test_CompoundStruct__free': everything-common.c:2766: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_CORBA_long__free': everything-common.c:2832: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_test_StrSeq__free': everything-common.c:2957: warning: unused parameter `dat' everything-common.c: In function `test_AnySeq__free': everything-common.c:3062: warning: implicit declaration of function `CORBA_sequence_CORBA_any__free' everything-common.c:3062: warning: return makes pointer from integer without a cast everything-common.c: In function `test_AnySeq__alloc': everything-common.c:3068: warning: implicit declaration of function `CORBA_sequence_CORBA_any__alloc' everything-common.c:3068: warning: return makes pointer from integer without a cast everything-common.c: In function `test_StructWithSequenceInIt__free': everything-common.c:3124: warning: unused parameter `dat' everything-common.c: In function `test_TestException__free': everything-common.c:3201: warning: unused parameter `dat' everything-common.c: In function `test_TestStruct2__free': everything-common.c:3234: warning: unused parameter `dat' everything-common.c: In function `test_TestException2__free': everything-common.c:3258: warning: unused parameter `dat' everything-common.c: In function `test_LongArray__free': everything-common.c:3283: warning: unused parameter `dat' everything-common.c:3283: warning: unused parameter `free_strings' everything-common.c: In function `test_StrArray__free': everything-common.c:3301: warning: unused parameter `dat' everything-common.c: In function `test_StrArrayMultiDimensional__free': everything-common.c:3327: warning: unused parameter `dat' everything-common.c: In function `test_VariableLengthStructArray__free': everything-common.c:3360: warning: unused parameter `dat' everything-common.c: In function `test_FixedLengthUnion__free': everything-common.c:3394: warning: unused parameter `dat' everything-common.c:3395: warning: unused parameter `free_strings' everything-common.c: In function `test_VariableLengthUnion__free': everything-common.c:3480: warning: unused parameter `dat' everything-common.c: In function `test_EnumUnion__free': everything-common.c:3525: warning: unused parameter `dat' everything-common.c:3525: warning: unused parameter `free_strings' everything-common.c: In function `test_BooleanUnion__free': everything-common.c:3553: warning: unused parameter `dat' everything-common.c: In function `test_StrArray2__free': everything-common.c:3585: warning: unused parameter `dat' everything-common.c: In function `test_ArrayUnion__free': everything-common.c:3611: warning: unused parameter `dat' everything-common.c: In function `FixedLengthStruct__free': everything-common.c:3643: warning: unused parameter `dat' everything-common.c:3644: warning: unused parameter `free_strings' everything-common.c: In function `VariableLengthStruct__free': everything-common.c:3664: warning: unused parameter `dat' everything-common.c: In function `CompoundStruct__free': everything-common.c:3689: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_CompoundStruct__free': everything-common.c:3792: warning: unused parameter `dat' everything-common.c: In function `CORBA_sequence_StrSeq__free': everything-common.c:3980: warning: unused parameter `dat' everything-common.c: In function `StructWithSequenceInIt__free': everything-common.c:4081: warning: unused parameter `dat' everything-common.c: In function `TestException__free': everything-common.c:4158: warning: unused parameter `dat' everything-common.c: In function `LongArray__free': everything-common.c:4190: warning: unused parameter `dat' everything-common.c:4190: warning: unused parameter `free_strings' everything-common.c: In function `StrArray__free': everything-common.c:4207: warning: unused parameter `dat' everything-common.c: In function `StrArrayMultiDimensional__free': everything-common.c:4231: warning: unused parameter `dat' everything-common.c: In function `VariableLengthStructArray__free': everything-common.c:4264: warning: unused parameter `dat' everything-common.c: In function `FixedLengthUnion__free': everything-common.c:4297: warning: unused parameter `dat' everything-common.c:4297: warning: unused parameter `free_strings' everything-common.c: In function `VariableLengthUnion__free': everything-common.c:4382: warning: unused parameter `dat' everything-common.c: In function `EnumUnion__free': everything-common.c:4427: warning: unused parameter `dat' everything-common.c:4427: warning: unused parameter `free_strings' everything-common.c: In function `BooleanUnion__free': everything-common.c:4454: warning: unused parameter `dat' everything-common.c: In function `StrArray2__free': everything-common.c:4485: warning: unused parameter `dat' everything-common.c: In function `ArrayUnion__free': everything-common.c:4509: warning: unused parameter `dat' make[3]: *** [everything-common.o] Error 1 make[2]: *** [all-recursive] Error 1 make[1]: *** [all-recursive] Error 1 make: *** [all-recursive] Error 1 ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-07 23:05 Message: Logged In: YES user_id=14486 I can't reproduce this. In the everything-common.c I have just generated, TC_CORBA_sequence_CORBA_any_struct is defined on lines 573 and 598 before being used on line 622. It being defined twice is probably a bug, but in ORBit, not ORBit-C++. Since this report is anonymous, I will close it if I do not receive more information about it. ---------------------------------------------------------------------- Comment By: Thibault Debatty (taibo) Date: 2001-09-10 12:49 Message: Logged In: YES user_id=320925 No !! I had to use an older version of orbit cpp. Sorry ---------------------------------------------------------------------- Comment By: Cecil Watson (cesman) Date: 2001-09-10 12:24 Message: Logged In: YES user_id=234924 Has this been resolved yet? If so, how? I have the same problem w/ Redhat 7.1. It is an out of the box install on a SMP PIII 650. Thanks in advance, Cecil ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=452143&group_id=646 |
|
From: <no...@so...> - 2001-12-08 06:57:04
|
Support Requests item #476299, was opened at 2001-10-30 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=476299&group_id=646 Category: None Group: None Status: Open Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Sam Couter (eddiesam) Summary: Pb with compilation ofORBit-C++ on HPUX Initial Comment: Product installed : ORBit 0.5.8 ORBit binutils 2.11 binutils gcc 2.95.3 gcc gettext 0.10.38 gettext glib 1.2.9 glib indent 2.2.6 indent libiconv 1.6.1 libiconv we try to compile orbitcpp-0.30.1 product : ======================================================================== = ============================ 3 [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1 >more run3 #/usr/bin/csh setenv LOCALHOME /opt ################# GLIB setenv CPPFLAGS "-I${LOCALHOME}/gcc/include -I${LOCALHOME}/ORBit/include -I${LOCALHOME}/glib/include -I${LOCALHOME}/gettext/include " echo "CPPFLAGS=" $CPPFLAGS setenv LDFLAGS "-L${LOCALHOME}/ORBit/lib -L${LOCALHOME}/glib/lib -L${LOCALHOME}/gettext/lib -L${LOCALHOME}/gcc/lib" echo "LDFLAGS= " $LDFLAGS The folowing lines describe the problems i have encountered during the generation of OrbitC++ ob HPUX platform : setenv SHLIB_PATH "${LOCALHOME}/ORBit/share:${LOCALHOME}/glib/share:${LOCALHOME}/gettext/share":$SHLIB_P A TH echo "SHLIB_PATH = " $SHLIB_PATH setenv PATH "/opt/gcc/bin:${LOCALHOME}/ORBit/bin:${LOCALHOME}/glib/bin:${LOCALHOME}/gettext/bin:${LO CALHOME}/binutils/bin:/usr/bin/:/usr/bin:" which gcc which ld echo "" echo "PATH = " $PATH echo "==============================================" ./configure --prefix=~egmconf/gnack/local ======================================================================== = ============================ [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1 >run3 CPPFLAGS= -I/opt/gcc/include -I/opt/ORBit/include -I/opt/glib/include -I/opt/gettext/include LDFLAGS= -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib SHLIB_PATH = /opt/ORBit/share:/opt/glib/share:/opt/gettext/share:/opt/ORBit/share:/opt/glib/share:/opt/gettext / share:/OUTILS/ilog/views401/views401/studio/hp32_11_3.05/shared:/OUTILS/ilog/views401/views 4 01/lib/hp32_11_3.05/shared /opt/gcc/bin/gcc /usr/bin//ld PATH = /opt/gcc/bin:/opt/ORBit/bin:/opt/glib/bin:/opt/gettext/bin:/opt/binutils/bin:/usr/bin/:/usr/bin: ============================================== loading cache ./config.cache checking for a BSD compatible install... ./install-sh -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... missing checking for working autoconf... missing checking for working automake... missing checking for working autoheader... missing checking for working makeinfo... missing checking whether to enable maintainer-specific portions of Makefiles... no checking for Cygwin environment... (cached) no checking for mingw32 environment... (cached) no checking how to run the C preprocessor... (cached) cc -E checking host system type... hppa2.0w-hp-hpux11.00 checking build system type... hppa2.0w-hp-hpux11.00 checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) works... yes checking whether the C compiler (gcc -g -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for ld used by GCC... (cached) /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... (cached) no checking for /usr/bin/ld option to reload object files... (cached) -r checking for BSD-compatible nm... (cached) /opt/binutils/bin/nm -B checking whether ln -s works... (cached) yes checking how to recognise dependant libraries... (cached) file_magic (s[0-9][0-9][0-9]|PA-RISC[0-9].[0-9]) shared library checking for object suffix... (cached) o checking for executable suffix... (cached) no checking command to parse /opt/binutils/bin/nm -B output... (cached) ok checking for dlfcn.h... (cached) yes checking for ranlib... (cached) ranlib checking for strip... (cached) strip checking for objdir... .libs checking for gcc option to produce PIC... (cached) -fPIC checking if gcc PIC flag -fPIC works... (cached) yes checking if gcc static flag -static works... (cached) yes checking if gcc supports -c -o file.o... (cached) yes checking if gcc supports -c -o file.lo... (cached) checking if gcc supports -fno-rtti -fno-exceptions... yes checking whether the linker (/usr/bin/ld) supports shared libraries... yes checking how to hardcode library paths into programs... relink checking whether stripping libraries is possible... yes checking dynamic linker characteristics... hpux11.00 dld.sl checking if libtool supports shared libraries... yes creating libtool checking for gcc... (cached) gcc checking whether the C compiler (gcc -g -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) works... yes checking whether the C compiler (gcc -g -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for c++... (cached) c++ checking whether the C++ compiler (c++ -g -Wall -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) works... yes checking whether the C++ compiler (c++ -g -Wall -L/opt/ORBit/lib -L/opt/glib/lib -L/opt/gettext/lib -L/opt/gcc/lib) is a cross-compiler... no checking whether we are using GNU C++... (cached) yes checking whether c++ accepts -g... (cached) yes checking for a BSD compatible install... ./install-sh -c checking for orbit-config... (cached) /opt/ORBit/bin/orbit-config checking for ORBit - version >= 0.5.7... yes checking for orbit-idl... (cached) /opt/ORBit/bin/orbit-idl checking for ANSI C header files... (cached) yes checking whether c++ compiler (c++) supports bad_cast... no checking whether orbit-idl supports --backenddir... yes updating cache ./config.cache creating ./config.status creating Makefile creating orb/Makefile creating orb/orbitcpp_constants.hh creating compiler/Makefile creating services/Makefile creating services/name/Makefile creating test/Makefile creating test/basic/Makefile creating test/basic/generated/Makefile creating test/everything/Makefile creating test/everything/generated/Makefile creating test/name/Makefile creating test/name/generated/Makefile creating test/any/Makefile creating test/any/generated/Makefile creating orbitcpp-config creating orb/orbitcpp_config.hh orb/orbitcpp_config.hh is unchanged ======================================================================== = ============================ 5 [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1 >make No suffix list. Making all in compiler Make: line 301: syntax error. Stop. *** Error exit code 1 Stop. ======================================================================== = ============================ 6 [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1 >cd compiler 8 [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1/compiler >\vi Makefile --> we comment the lines : DEPS_MAGIC := $(shell mkdir .deps > /dev/null 2>&1 || :) -include $(DEP_FILES) ======================================================================== = ============================ 1 [helicon:egmconf] /HELICON1/EGM/MISH2/gnack/orbitcpp-0.30.1 >make No suffix list. Making all in compiler /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I../orb -I.. -I.. -I/opt/glib/include -I/opt/glib/include/glib-1.2 -I/opt/glib/lib/glib/include -I/opt/ORBit/include -I/opt/gcc/include -I/opt/ORBit/include -I/opt/glib/include -I/opt/gettext/include -g -O0 -Wall -c base.cc rm -f .libs/base.lo c++ -DHAVE_CONFIG_H -I. -I. -I../orb -I.. -I.. -I/opt/glib/include -I/opt/glib/include/glib-1.2 -I/opt/glib/lib/glib/include -I/opt/ORBit/include -I/opt/gcc/include -I/opt/ORBit/include -I/opt/glib/include -I/opt/gettext/include -g -O0 -Wall -c base.cc -fPIC -DPIC -o .libs/base.lo In file included from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/cstdio:6, from base.cc:30: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:26: warning: this is the location of the previous definition In file included from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/cctype:6, from base.cc:31: /usr/include/ctype.h:26: warning: `__va__list' redefined /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/stdio.h:30: warning: this is the location of the previous definition In file included from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/cstring:7, from base.cc:29: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:51: warning: declaration of `int memcmp(const void *, const void *, long unsigned int)' /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:51: warning: conflicts with built-in declaration `int memcmp(const void *, const void *, unsigned int)' /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:116: warning: declaration of `void * memcpy(void *, const void *, long unsigned int)' /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:116: warning: conflicts with built-in declaration `void * memcpy(void *, const void *, unsigned int)' /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:133: warning: declaration of `size_t strlen(const char *)' /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/include/string.h:133: warning: conflicts with built-in declaration `unsigned int strlen(const char *)' In file included from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/string:6, from base.hh:36, from base.cc:32: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/std/bastring.h:112: `operator new' takes type `size_t' as first parameter In file included from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/std/bastring.h:655, from /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/string:6, from base.hh:36, from base.cc:32: /opt/gcc/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.3/../../../../include/g++-3/std/bastring.cc:32: `operator new' takes type `size_t' as first parameter *** Error exit code 1 Stop. *** Error exit code 1 Stop. Can you help us ??? Thank you very much !! ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-07 22:56 Message: Logged In: YES user_id=14486 Firstly: ORBit-C++ requires GNU make to compile, and from the first error message it looks like you're using another make. Secondly: The other errors I see are problems in the header files from GCC, or in GCC, or maybe in your system headers, but almost definately not in ORBit-C++. Thirdly: This bug is anonymous, so I don't know how to get more information from you, or see if you still have the problem. If I receive no more information on this support request, I will close it. ---------------------------------------------------------------------- Comment By: Jean-Pierre PEYRI (peyrijp) Date: 2001-11-06 00:07 Message: Logged In: YES user_id=368151 Pb with orbitcpp-0.30.1 compilation on HP-UX platform ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=200646&aid=476299&group_id=646 |
|
From: <no...@so...> - 2001-12-08 06:49:22
|
Bugs item #475580, was opened at 2001-10-27 09:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Francesco Lamonica (franci) >Assigned to: Sam Couter (eddiesam) Summary: Compilation fail Initial Comment: Compilation fails on the test suite (at least in slackware 7.x and 8). This is due to the static linking against the glib.a libraray... maybe the compiler (gcc 2.95.3) should be explicitly told that is a static lib (static linking has always been a little annoying). Btw adding the -lglib flags made the compilation go smoothlessly ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-07 22:49 Message: Logged In: YES user_id=14486 Francesco: Can you provide more information on this? Can you explain how the static linking causes problems? I don't have any problems, using gcc 2.95.4 20011006. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=475580&group_id=646 |
|
From: <no...@so...> - 2001-12-08 06:35:38
|
Bugs item #437571, was opened at 2001-06-30 07:50 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=437571&group_id=646 Category: None Group: None Status: Open >Resolution: Postponed Priority: 5 Submitted By: Nobody/Anonymous (nobody) >Assigned to: Sam Couter (eddiesam) Summary: error while compiling Initial Comment: Making all in services make[1]: Entering directory `/usr/local/orbitcpp-0.30/services' Making all in name make[2]: Entering directory `/usr/local/orbitcpp-0.30/services/name' /opt/gnome/bin/orbit-idl -l c++ --backenddir=../../compiler/.libs ./CosNaming.id ** WARNING **: Module load failed: ../../compiler/.libs/liborbit-idl-c++-backend ** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend): asserti ** WARNING **: ./CosNaming.idl compilation failed sed -e 's/#include \CosNaming.h\/#include \ORBitservices/CosNaming.h\/' Co sed: can't read CosNaming-cpp-common.hh: No such file or directory make[2]: *** [CosNaming.cc] Error 2 make[2]: Leaving directory `/usr/local/orbitcpp-0.30/services/name' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/usr/local/orbitcpp-0.30/services' make: *** [all-recursive] Error 1r ---------------------------------------------------------------------- >Comment By: Sam Couter (eddiesam) Date: 2001-12-07 22:35 Message: Logged In: YES user_id=14486 I need more information to work this one out. I can't reproduce it, and since it was submitted anonymously, I will close it if I do not receive more information. I need to know if this still happens with 0.30.2, and what versions of ORBit and glib are installed, as well as what compilation options were used. ---------------------------------------------------------------------- Comment By: Francesco Lamonica (franci) Date: 2001-10-25 06:54 Message: Logged In: YES user_id=1349 have u stripped the Orbit libs? that was causing a similar error on my box (slack 8 with gcc 2.95.3) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-30 07:54 Message: Logged In: NO btw: running Slackware 7.1 Kernel 2.4.5 gcc 2.95.3 ORBit 0.5.8 (get same errs with other packages, so it's prob me!!) ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2001-06-30 07:53 Message: Logged In: NO btw: running Slackware 7.1 Kernel 2.4.5 gcc 2.95.3 ORBit 0.5.8 (get same errs with other packages, so it's prob me!!) ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=437571&group_id=646 |
|
From: Sam C. <sa...@to...> - 2001-12-08 06:15:22
|
Braden, It's been a while since we last discussed ORBit-C++. Are you still interested in helping out? I have more time to work on it now. Braden McDaniel <br...@en...> wrote: > The reason this would be necessary is that libtool doesn't provide a > means to selectively build shared/static libs on a per-library basis. > This selection is done per configure script. I've thought about this a bit, and I now agree that a seperate configure script for the orbit-idl compiler plugin would be useful. The main reason I didn't want one before is additional complexity, but I see it as necessary now. There is also a second problem which it would allow us to solve: The compiler plugin library should be a .so file with no versioning and no symlinks, and the soname should match the filename. I've merged your other patches (RPM spec file, "make distclean" fix) into the CVS repository. Feel free to send more for building the compiler component with a seperate configure script, the other build problems you've mentioned, or anything else you have fixed. --=20 Sam Couter | Internet Engineer | http://www.topic.com.au/ sa...@to... | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C |
|
From: Sam C. <sa...@to...> - 2001-12-08 05:42:10
|
Brian May <ba...@sn...> wrote: >=20 > Why is it that when ever I make any changes to my code, including just > adding debug print messages and/or removing the code which caused it > to crash last time, it always crashes in a completely different way > :-( >=20 > Now, for instance, that crash I described before is no longer > happening, instead it crashes after the function returns. >=20 > I have even seen errors I have never seen before, like "illegal > instruction" and "trace trap". Wow! >=20 > I have this insane feeling that debugging this simply program could be > rather difficult. :-( Sounds like you need a malloc debugger like ElectricFence, NJAMD, dmalloc, etc. Since I know you're using Debian, I can tell you that Debian has about a million of them, all of which work differently. Each of them is effective against different kinds of bugs. --=20 Sam Couter | Internet Engineer | http://www.topic.com.au/ sa...@to... | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C |
|
From: Brian M. <ba...@sn...> - 2001-12-08 01:43:48
|
>>>>> "Brian" == Brian May <ba...@sn...> writes:
Brian> Oops! maybe I should have stayed in bed :-(
Why is it that when ever I make any changes to my code, including just
adding debug print messages and/or removing the code which caused it
to crash last time, it always crashes in a completely different way
:-(
Now, for instance, that crash I described before is no longer
happening, instead it crashes after the function returns.
I have even seen errors I have never seen before, like "illegal
instruction" and "trace trap". Wow!
I have this insane feeling that debugging this simply program could be
rather difficult. :-(
--
Brian May <ba...@sn...>
|
|
From: Brian M. <ba...@sn...> - 2001-12-08 01:15:26
|
>>>>> "Sam" == Sam Couter <sa...@to...> writes:
Sam> Brian May <ba...@sn...> wrote:
>> I have looked up the C++ language mapping standard, but can't
>> find anything on activating or deactivating objects.
Sam> Phil got some code working before Real Life took him away
Sam> from the project. His instructions are in the archive at:
Sam> http://www.geocrawler.com/mail/msg.php3?msg_id=4560050&list=835
Thanks. Although now I realize that my code won't even execute up to
that point :-(
after much experimentation with other crashes, I seem to have fixed
them for now...
...now even gdb is crashing:
[544] [scrooge:bam] ~/cvswork/atcsim/src >gdb ./aircrafts
GNU gdb 5.0.90-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...
(gdb) r
Starting program: /home/bam/cvswork/atcsim/src/./aircrafts
zsh: segmentation fault gdb ./aircrafts
Oops! maybe I should have stayed in bed :-(
lets try a different approach:
[544] [scrooge:bam] ~/cvswork/atcsim/src >ulimit -c unlimited
[547] [scrooge:bam] ~/cvswork/atcsim/src >gdb ./aircrafts core
GNU gdb 5.0.90-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...
Core was generated by `./aircrafts'.
Program terminated with signal 11, Segmentation fault.
(gdb) bt
#0 0xbffff797 in ?? ()
#1 0x400992c8 in _orbitcpp::release_guarded () from /usr/lib/liborbitcpp.so.0
#2 0x08069571 in CORBA::release (o=0xbffff71c)
at /usr/include/orb/orbitcpp_object.hh:110
#3 0x0806a686 in _orbitcpp::ObjectPtr_var<Atcsim::A_Aircraft, _orbitcpp::stub::Atcsim::A_Aircraft *>::free (this=0xbffff634)
at /usr/include/orb/orbitcpp_smartptr.hh:122
#4 0x08069bd7 in _orbitcpp::ObjectPtr_var<Atcsim::A_Aircraft, _orbitcpp::stub::Atcsim::A_Aircraft *>::~ObjectPtr_var (this=0xbffff634, __in_chrg=2)
at /usr/include/orb/orbitcpp_smartptr.hh:76
#5 0x08068b2e in Aircrafts_impl::destroy (this=0xbffff95c, aref=@0xbffff6a4)
at aircrafts.cc:113
This is probably one big problem with using CORBA C and C++ bindings,
it is so easy to do something wrong, but the error doesn't show up
until much later :-(.
Anyway, the code in question at line 113 of aircrafts.cc is
A_Aircraft_var aircraft_var = aref.aircraft;
where aref is a CORBA structure containing a member "aircraft" which
is a reference to a CORBA interface. I am trying to copy the reference
to another variable. Am I doing anything wrong here?
Oh, one other question, perhaps more CORBA specific, how do people
choose CORBA variable/interface/type names?
Traditionally, I use:
type=NOUN variable=noun
However, this doesn't work in CORBA, because (IIRC) some languages do
not support distinguishing lower case from upper case.
So I have tried:
type=A_NOUN variable=noun
However, not only does that look ugly, but it triggers the warning
that underscores should be avoided.
--
Brian May <ba...@sn...>
|
|
From: Diego S. R. <dse...@di...> - 2001-12-07 12:50:33
|
All, MC>=20 MC> I suggest that we take up Michael and Mark's offer of integrating thi= s MC> into the main ORBit2 code base, even if it's just to get more people MC> involved. I would be interested in helping. Depending on my time and knowledge if y= ou agree. I have some CORBA knowledge that may help. Best regards. diego. --=20 Diego Sevilla Ruiz -- http://ditec.um.es/~dsevilla/ -- dse...@um... Dep. Ingenier=EDa y Tecnolog=EDa de Computadores, Facultad de Inform=E1ti= ca Univ.de Murcia,Campus Espinardo,30080 Murcia (SPAIN),Tel.+34968367658 lynx -dump ditec.um.es/~dsevilla/face |uncompface | ikon2xbm |display PGP: http://pgp.rediris.es:11371/pks/lookup?op=3Dget&search=3D0xC9B964B7 perl -e'$_=3D"\x4\@FLe\x2&B";for(/../g){print unpack("b*",$_),"\n"}'|tr 0= 1 " #" (lambda x,f=3Dlambda x,f:x and x[-1]+f(x[:-1],f):f(x,f))('se.mu@allivesd'= ) |
|
From: Sam C. <sa...@to...> - 2001-12-07 07:06:57
|
Brian May <ba...@sn...> wrote: > I have looked up the C++ language mapping standard, but can't find > anything on activating or deactivating objects. Phil got some code working before Real Life took him away from the project. His instructions are in the archive at: http://www.geocrawler.com/mail/msg.php3?msg_id=3D4560050&list=3D835 > I have tried looking up the sample C++ code referred to in various > places, eg. the FAQ referred to on the website > <URL:http://orbit-resource.sourceforge.net/cpp.html> refers to > <URL:http://www.geocrawler.com/archives/3/835/2000/7/0/4066792/>, > which refers to sample code at > <URL:ftp://orbitcpp.sourceforge.net/pub/orbitcpp> but haven't been > able to access it (connection refused). I don't know what example code used to be there, but I don't think I've ever seen it. --=20 Sam Couter | Internet Engineer | http://www.topic.com.au/ sa...@to... | tSA Consulting | OpenPGP key ID: DE89C75C, available on key servers OpenPGP fingerprint: A46B 9BB5 3148 7BEA 1F05 5BD5 8530 03AE DE89 C75C |
|
From: <no...@so...> - 2001-12-07 06:48:36
|
Patches item #473054, was opened at 2001-10-20 01:33 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=473054&group_id=646 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Braden McDaniel (braden) >Assigned to: Sam Couter (eddiesam) Summary: RPM spec file Initial Comment: An RPM spec file. Actually, this file is input for configure; configure produces the actual spec file. ---------------------------------------------------------------------- Comment By: Braden McDaniel (braden) Date: 2001-10-22 03:01 Message: Logged In: YES user_id=16099 Updated spec file includes the compiler backend in orbitcpp-devel instead of orbitcpp. ---------------------------------------------------------------------- Comment By: Braden McDaniel (braden) Date: 2001-10-20 01:37 Message: Logged In: YES user_id=16099 This patch to configure.in and the root Makefile.am makes configure process orbitcpp.spec.in to produce orbitcpp.spec, and puts orbitcpp.spec in the distribution. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=473054&group_id=646 |
|
From: <no...@so...> - 2001-12-07 06:33:11
|
Bugs item #472990, was opened at 2001-10-19 20:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=472990&group_id=646 Category: None Group: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Braden McDaniel (braden) >Assigned to: Sam Couter (eddiesam) >Summary: "make distclean" is broken Initial Comment: "make distclean" fails in test/any/generated. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=100646&aid=472990&group_id=646 |
|
From: Brian M. <ba...@sn...> - 2001-12-07 06:33:01
|
Hello,
After not using ORBit for a while, I am finally back again, and trying
to get my old program back up and running, using C++ bindings to
ORBit.
However, one question: How do a create a method that will destroy an
object at the server end?
I believe I need to call deactive_object to prevent ORBit from using
it anymore, and then delete the C++ implementation class.
The first step is easy, but the next step is where I am having
problems - freeing the C++ implementation class. In particular, I
cannot seem to convert the reference to the object into the pointer to
the implementation class (yes - this is on the server). Isn't this the
function of reference_to_servant?
I have tried:
void destroy(const A_Aircraft::A_AREF &aref) {
A_Aircraft_var aircraft_var = aref.aircraft;
PortableServer::ObjectId_var objid = poa->reference_to_id(aircraft_var);
Aircraft_impl *aircraft_impl = poa->reference_to_servant(aircraft_var);
poa->deactivate_object(*objid);
delete(aircraft_impl);
}
However, not unexpectedly, the compiler complains on the Aircraft_impl
line:
aircrafts.cc: In method `void Aircrafts_impl::destroy(const Atcsim::A_Aircraft::A_AREF &)':
aircrafts.cc:115: type `Aircraft_impl' is not a base type for type `PortableServer::ServantBase'
Just out of interest I tried casting it to (Aircraft_impl *), but that
doesn't work either:
aircrafts.cc: In method `void Aircrafts_impl::destroy(const Atcsim::A_Aircraft::A_AREF &)':
aircrafts.cc:115: cannot cast up from virtual baseclass `PortableServer::ServantBase'
make[1]: *** [aircrafts.o] Error 1
I have looked up the C++ language mapping standard, but can't find
anything on activating or deactivating objects.
I have tried looking up the sample C++ code referred to in various
places, eg. the FAQ referred to on the website
<URL:http://orbit-resource.sourceforge.net/cpp.html> refers to
<URL:http://www.geocrawler.com/archives/3/835/2000/7/0/4066792/>,
which refers to sample code at
<URL:ftp://orbitcpp.sourceforge.net/pub/orbitcpp> but haven't been
able to access it (connection refused).
Any ideas?
Thanks in advance.
--
Brian May <ba...@sn...>
|
|
From: <no...@so...> - 2001-12-07 06:25:53
|
Patches item #472998, was opened at 2001-10-19 20:55 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=472998&group_id=646 Category: None Group: None >Status: Closed >Resolution: Accepted Priority: 5 Submitted By: Braden McDaniel (braden) >Assigned to: Sam Couter (eddiesam) >Summary: "make distclean" fix Initial Comment: Fixes "make distclean" (bug 427990) by disabling automake's dependency tracking for some of the test subdirectories. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=300646&aid=472998&group_id=646 |
|
From: <bb...@ya...> - 2001-12-06 22:20:47
|
> - How ORBit finds the appropriate stuff from just "c++". > - What libraries it uses for this. > - What C interfaces those libraries implement. The -lLANG or --language=LANG instructs ORBit to dlopen a shared library called liborbit-idl-LANG-backend.so. This lib provides entry points that implement the basic liborbit interface routines. The backend lib needs to be located in either the standard orbit backend libs location or it can be defined with --backenddir=<path> in ORBit-0.57 (or maybe earlier) onwards. I haven't seen documentation on the interface that is implemented by the backend lib. Never paid attention to that end of things. : ( I assume this info is contained somewhere in the doc for ORBit. The ORBit mailing list is probably a good place to ask about the interface definition. http://shopping.yahoo.com.au - Yahoo! Shopping - Free CDs for thousands of Priority Shoppers! |
1818 messages has been excluded from this view by a project administrator.
