orbitcpp-list

[orbitcpp-list] 2 questions

[Antony S. <an...@mi...>]

1) Is there a FAQ for this mailing list - or for orbit-cpp?

2) Are there RPMs of orbit-cpp available?

Thanks for any info.

--
- Antony Suter  (an...@mi...)  "Exner"  openpgp:7916EE67
- "...to condense fact from the vapor of nuance."

[orbitcpp-list] Another bug with #included idl file

[Kuba <kp...@po...>]

Hi,

I have found another problem, when you're #including one idl from another.
Situation is as follows.
We have two idl files:

file1.idl:

module A {
  interface Empty {
  };
};

file2.idl:

#include <file1.idl>
module A {
  struct SomeStruct {
    string SomeString;
  };

  interface NotEmpty {
    void SomeFunction (int SomeStruct inParam);
  };
};

Trying to compile file2.idl causes orbit-idl c++ compiler to complain, that SomeStruct is unknown.
The reason for that is fact, that in IDL_Tree analyzed by compiler there are two subtrees for module A. When searching for SomeStruct function lookupLocal
from language.cc looks into the first module A subtree only, so it doesn't find SomeStruct declared in the second subtree.
Here is a patch (sorry for some garbage inside, my editor cuts white spaces at the end of the lines - the only changed functions are lookupLocal () and getScope):
----------------------------------------------------------
diff -u compiler/language.cc compiler.new/language.cc
--- compiler/language.cc	Fri Apr  6 11:41:42 2001
+++ compiler.new/language.cc	Sun Apr 22 00:05:24 2001
@@ -95,7 +95,7 @@
 			switch (IDL_UNARYOP(constant).op) {
 				case IDL_UNARYOP_PLUS: op = '+'; break;
 				case IDL_UNARYOP_MINUS: op = '-'; break;
-				case IDL_UNARYOP_COMPLEMENT: op = '~'; 
+				case IDL_UNARYOP_COMPLEMENT: op = '~';
 			}
 			return string("(") + op + idlTranslateConstant(IDL_UNARYOP(constant).operand,scope) + ")";
 		}
@@ -111,7 +111,7 @@
 				case IDL_BINOP_SUB: op = "-"; break;
 				case IDL_BINOP_MULT: op = "*"; break;
 				case IDL_BINOP_DIV: op = "/"; break;
-				case IDL_BINOP_MOD: op = "%"; 
+				case IDL_BINOP_MOD: op = "%";
 			}
 			return '(' + idlTranslateConstant(IDL_BINOP(constant).left,scope) +
 				op + idlTranslateConstant(IDL_BINOP(constant).right,scope) + ')';
@@ -135,7 +135,7 @@
 		IDLElement *slot = parentscope->getItem(id);
 
 		// I've removed the following check, since forward dcls mean that
-		// there can be duplicate identifiers -PD  
+		// there can be duplicate identifiers -PD
 		// okay, libIDL should catch all real evil cases for us anyway. -andy
 		//if (slot) throw IDLExDuplicateIdentifier(node,*parentscope,m_identifier);
 
@@ -152,7 +152,7 @@
 
 
 
-string 
+string
 IDLElement::getQualifiedIDLIdentifier(IDLScope const *up_to,
         IDLScope const *assumed_base = NULL) const {
 	if (up_to == this) return "";
@@ -170,7 +170,7 @@
 
 
 
-string 
+string
 IDLElement::getQualifiedCIdentifier(IDLScope const *up_to,
         IDLScope const *assumed_base = NULL) const {
 	if (up_to == this) return "";
@@ -190,7 +190,7 @@
 
 
 
-string 
+string
 IDLElement::getQualifiedCPPIdentifier(IDLScope const *up_to,
         IDLScope const *assumed_base = NULL) const {
 	if (up_to == this) return "";
@@ -275,20 +275,26 @@
 	string::size_type first = 0;
 
 	string::size_type nextscopeq = id.find("::",first);
-	while (nextscopeq != string::npos) {
-		IDLScope *nextscope = scope->getScope(id.substr(first,nextscopeq-first));
-		if (!nextscope) return NULL;
-		scope = nextscope;
-		first = nextscopeq + 2;
-		nextscopeq = id.find("::",first);
+	if (nextscopeq == string::npos) {
+		return scope->getItem(id.substr(first));
+	}
+	else {
+		int spos = 0;
+		IDLScope *nextscope = NULL;
+		while ((nextscope = scope->getScope(id.substr(first,nextscopeq-first),spos)) != NULL) {
+			spos++;
+			IDLElement* element = nextscope->lookupLocal(id.substr(nextscopeq+2,id.length()-nextscopeq-2));
+			if (element != NULL) return element;
+		}
 	}
 
-	return scope->getItem(id.substr(first));
+	return NULL;
 }
 
 
 
 
+
 IDLElement *
 IDLScope::getItem(IDL_tree node) const {
 	ItemList::const_iterator first = m_items.begin(),last = m_items.end();
@@ -317,14 +323,23 @@
 
 
 
-IDLScope *
-IDLScope::getScope(string const &id) const {
-	ScopeList::const_iterator first = m_scopes.begin(),last = m_scopes.end();
+IDLScope*
+IDLScope::getScope (string const &id, int &spos) const {
+	ScopeList::const_iterator first = m_scopes.begin(), last = m_scopes.end ();
+	string IDLIdentifier;
 
+	int pos_counter = 0;
 	while (first != last) {
-		if ((*first)->getIDLIdentifier() == id) return *first;
+		IDLIdentifier = (*first)->getIDLIdentifier();
+		if ((*first)->getIDLIdentifier() == id && pos_counter >= spos) {
+			spos = pos_counter;
+			return *first;
+		}
+
 		first++;
+		pos_counter++;
 	}
+
 	return NULL;
 }
 
@@ -358,7 +373,7 @@
 
 
 
-void 
+void
 IDLScope::getCPPNamespaceDecl(string &ns_begin,string &ns_end,
                                     string const &prefix) {
 	IDLScope const *scope = this;
@@ -396,9 +411,9 @@
 		list = IDL_LIST(list).next;
 	}	
 }
- 
+
 // IDLOperation ---------------------------------------------------------------
-string 
+string
 IDLOperation::getCPPOpParameterList() {
 	string result;
 	vector<ParameterInfo>::const_iterator
@@ -418,7 +433,7 @@
 
 
 
-string 
+string
 IDLOperation::getCOpParameterList() {
 	string result;
 	vector<ParameterInfo>::const_iterator
diff -u compiler/language.hh compiler.new/language.hh
--- compiler/language.hh	Mon Jan 22 08:44:05 2001
+++ compiler.new/language.hh	Sun Apr 22 00:04:43 2001
@@ -129,7 +129,7 @@
 
 	IDLElement *getItem(IDL_tree node) const;
 	IDLElement *getItem(string const &id) const;
-	IDLScope *getScope(string const &id) const;
+	IDLScope *getScope (string const &id, int &spos) const;
 	IDLScope const *getRootScope() const {
 		if (getParentScope()) return Super::getRootScope();
 		else return this;
@@ -209,7 +209,7 @@
 	typedef std::list<std::string>  LabelList;
 	typedef LabelList::const_iterator  const_iterator;
 private:
-	IDLMember *m_member;  
+	IDLMember *m_member;
 	LabelList m_labels;
 	bool m_isDefault;
 public:
@@ -220,7 +220,7 @@
 	~IDLCaseStmt() {
 		delete m_member;
 	}
-  
+
 	IDLMember const &getMember() {
 		return *m_member;
 	}
@@ -271,7 +271,7 @@
 
 	IDLType 		*m_type;
 	bool            m_readOnly;
-  
+
 public:
 
 	IDLAttribute(string const &id,IDL_tree node,IDLType *type,IDLScope *parentscope = NULL)
--------------------------------------------------------


-- 
26 maja - Dzien Matki. Wygraj kwiaty dla swojej Mamy!
Do rozdania 75 bukietow z dostawa i zyczeniami.
[ http://zakupy.onet.pl/prezenty.asp?k=7 ]

[orbitcpp-list] a patch for orbitcpp_sequence.hh

[Laszlo M. <las...@et...>]

Hi,

I've found a bug in SequenceBase(SequenceBase const &src) in case of
src.m_target._maximum == 0. A similar problem is already corrected for
op= in the cvs, now here is my fix for the copy ctor.

In the second hunk I removed an unused variable which greatly reduced
the warning noise.

bye,Laszlo

ps: apply this using "patch -l"

--- orbitcpp_sequence.hh.orig	Fri May 11 12:12:17 2001
+++ orbitcpp_sequence.hh	Fri May 11 12:24:42 2001
@@ -66,8 +66,10 @@
 		SequenceBase(SequenceBase const &src) {
 			m_target = src.m_target;

+			if (m_target._maximum) {
 				m_target._buffer = SEQ::allocbuf(m_target._maximum);
 				if (!m_target._buffer) throw CORBA::NO_MEMORY();
+			}

 			try {
 				for (CORBA::ULong i = 0;i<m_target._length;i++)
@@ -247,7 +253,7 @@

 #define ORBITCPP_DECLARE_SIMPLE_SEQUENCE(COMPONENT,ALLOC_FUNC,ALLOCBUF_FUNC,C_NAME,NAME) \
 	typedef _orbitcpp::UnboundedSequenceTmpl< COMPONENT,C_NAME> NAME; \
-	inline void *NAME::operator new(CORBA::ULong size) { \
+	inline void *NAME::operator new(CORBA::ULong) { \
 		return ALLOC_FUNC(); \
 	} \
 	inline void NAME::operator delete(void *seq) { \

[orbitcpp-list] project status

[<sam...@ti...>]

Hi everybody!
I'm an italian student; I'm to begin a project with ORBit and I'd like to implement it with C++. I'd like to have last news about the status of your project and it's 'usability' for real and complex projects.

Thanks & bye
Samuele

Re: [orbitcpp-list] Bug in Installation Script: Installing orbitcpp in Irix

[Richard A. <ric...@ix...>]

Could you submit a patch?


On Mon, 07 May 2001 23:24:07 Oscar De Bustos wrote:
> Hi guys. Resolved problem.
> 
> I have installed ORBitcpp in Irix!!!. There was a bug in a Makefile that
> I
> have resolved.
> In /fw_orbitcpp/orbitcpp-0.30/test/basic/Makefile in line 104:
> 
> After: client_LDADD = $(LDADDS) generated/lib$(testname).a
> Before: client_LDADD = generated/lib$(testname).a $(LDADDS) 
> 

RE: [orbitcpp-list] Bug in Installation Script: Installing orbitc pp in Irix

[Oscar De B. <ob...@sg...>]

Oopps is so:

In /fw_orbitcpp/orbitcpp-0.30/test/basic/Makefile in line 104:

Before : client_LDADD =3D $(LDADDS) generated/lib$(testname).a
After  : client_LDADD =3D generated/lib$(testname).a $(LDADDS)

Best Regards.

Silicon Graphics, S.A. Sociedad Unipersonal
Plaza del Descubridor Diego de Ord=E1s 3
Tel:+34 91 398 42 00
Edificio Santa Engracia 120
Fax:+34 91 398 42 01
28003 Madrid
E-mail: ob...@ma...
V-mail: 6-368-4273

NB:  INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL.  IT IS INTENDED =
SOLELY
FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED,
DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT.  IF YOU ARE NOT
THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE,
DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED
COPIES.



-----Original Message-----
From: Oscar De Bustos [mailto:ob...@sg...]
Sent: Monday, May 07, 2001 3:24 PM
To: 'orb...@li...'
Subject: [orbitcpp-list] Bug in Installation Script: Installing =
orbitcpp
in Irix


Hi guys. Resolved problem.

I have installed ORBitcpp in Irix!!!. There was a bug in a Makefile =
that I
have resolved.
In /fw_orbitcpp/orbitcpp-0.30/test/basic/Makefile in line 104:

After: client_LDADD =3D $(LDADDS) generated/lib$(testname).a
Before: client_LDADD =3D generated/lib$(testname).a $(LDADDS)=20

Easy, no?

Best Regards.

Silicon Graphics, S.A. Sociedad Unipersonal
Plaza del Descubridor Diego de Ord=E1s 3
Tel:+34 91 398 42 00
Edificio Santa Engracia 120
Fax:+34 91 398 42 01
28003 Madrid
E-mail: ob...@ma...
V-mail: 6-368-4273

NB:  INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL.  IT IS INTENDED =
SOLELY
FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED,
DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT.  IF YOU ARE NOT
THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE,
DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED
COPIES.



_______________________________________________
orbitcpp-list mailing list
orb...@li...
http://lists.sourceforge.net/lists/listinfo/orbitcpp-list

[orbitcpp-list] Bug in Installation Script: Installing orbitcpp in Irix

[Oscar De B. <ob...@sg...>]

Hi guys. Resolved problem.

I have installed ORBitcpp in Irix!!!. There was a bug in a Makefile =
that I
have resolved.
In /fw_orbitcpp/orbitcpp-0.30/test/basic/Makefile in line 104:

After: client_LDADD =3D $(LDADDS) generated/lib$(testname).a
Before: client_LDADD =3D generated/lib$(testname).a $(LDADDS)=20

Easy, no?

Best Regards.

Silicon Graphics, S.A. Sociedad Unipersonal
Plaza del Descubridor Diego de Ord=E1s 3
Tel:+34 91 398 42 00
Edificio Santa Engracia 120
Fax:+34 91 398 42 01
28003 Madrid
E-mail: ob...@ma...
V-mail: 6-368-4273

NB:  INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL.  IT IS INTENDED =
SOLELY
FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED,
DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT.  IF YOU ARE NOT
THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE,
DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED
COPIES.

[orbitcpp-list] Installing orbitcpp in Irix

[Oscar De B. <ob...@sg...>]

Hi guys.

I am installing ORBit-c++ 0.3 in Irix 6.5. I have installed gcc,glib, ORB=
it
0.5.7,libstdc++-2.8.1 but when I execute configure, I obtain the followin=
g
linking error:=20

                           c++ -g -Wall -o .libs/client client.o
../../orb/.libs/liborbitcpp.so=20
                           -L/usr/freeware/lib32 -lORBit -lIIOP=20
                           -lORBitutil -lglib -lm -lstdc++
-L/usr/freeware/lib32 -lORBit -lIIOP -lORBitutil=20
                           -lglib -lm -lm=20
                           generated/libbasic.a -Wl,-rpath
-Wl,/usr/local/lib=20
                           ld32: WARNING 84 :=20
=20
/usr/freeware/lib/gcc-lib/mips-sgi-irix6.2/2.95.2/libstdc++.a is not used
for=20
                           resolving any symbol.=20
                           ld32: WARNING 127: Two shared objects with the
same soname,=20
                           /usr/lib32/mips3/libm.so and=20
                           /usr/lib32/libm.so, have been been linked. Thi=
s
is probably due to a missing -L=20
                           specification.=20
                           Ignoring the latter.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "_orbitcpp::CEnvironment::CEnvironment(void)" =
--
1st referenced by=20
                           generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "_orbitcpp::CEnvironment::~CEnvironment(void)"=
 --
1st referenced by=20
                           generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"CORBA_exception_id"=20
                           -- 1st referenced by
generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when=20
                           and which objects, archives and dsos are loade=
d.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "CORBA_exception_value" -- 1st referenced by=20
                           generated/libbasic.a(basic-cpp.o).=20
                           Use linker=20
                           option -v to see when and which objects, archi=
ves
and dsos are loaded.=20
                           ld32: ERROR 33 :=20
                           Unresolved text symbol "_orbitcpp::error(char =
*)"
-- 1st referenced by=20
                           generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
=20
"_orbitcpp::CEnvironment::propagate_sysex_guts(void)" -- 1st referenced b=
y=20
                           generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"CORBA_exception_set"=20
                           -- 1st referenced by
generated/libbasic.a(basic-cpp.o).=20
                           Use linker option -v to see when=20
                           and which objects, archives and dsos are loade=
d.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "_ORBit_object_get_connection" -- 1st referenc=
ed
by=20
                           generated/libbasic.a(basic-stubs.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol
"ORBit_default_principal_iovec" -- 1st referenced=20
                           by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "giop_send_request_buffer_use" -- 1st referenc=
ed
by=20
                           generated/libbasic.a(basic-stubs.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol
"giop_send_buffer_write" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "giop_send_buffer_unuse" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use=20
                           linker option -v to see when and which objects=
,
archives and dsos are loaded.=20
                           ld32: ERROR 33=20
                           : Unresolved text symbol
"giop_recv_reply_buffer_use_2" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"giop_recv_buffer_use"=20
                           -- 1st referenced by
generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when=20
                           and which objects, archives and dsos are loade=
d.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "CORBA_exception_set_system" -- 1st referenced=
 by

                           generated/libbasic.a(basic-stubs.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol
"ORBit_delete_profiles" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"ORBit_demarshal_IOR"=20
                           -- 1st referenced by
generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when=20
                           and which objects, archives and dsos are loade=
d.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "ORBit_object_get_forwarded_connection" -- 1st
referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "ORBit_handle_exception" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use=20
                           linker option -v to see when and which objects=
,
archives and dsos are loaded.=20
                           ld32: ERROR 33=20
                           : Unresolved text symbol
"giop_message_buffer_do_alignment" -- 1st=20
                           referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "giop_message_buffer_append_mem" -- 1st
referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol "CORBA_string_allo=
c"
-- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"ORBit_marshal_object"=20
                           -- 1st referenced by
generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when=20
                           and which objects, archives and dsos are loade=
d.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "CORBA_Object_release" -- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use=20
                           linker option -v to see when and which objects=
,
archives and dsos are loaded.=20
                           ld32: ERROR 33=20
                           : Unresolved text symbol "ORBit_demarshal_obje=
ct"
-- 1st referenced by=20
                           generated/libbasic.a(basic-stubs.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "giop_send_reply_buffer_use" -- 1st referenced=
 by

                           generated/libbasic.a(basic-skels.o).=20
                           Use=20
                           linker option -v to see when and which objects=
,
archives and dsos are loaded.=20
                           ld32: ERROR 33=20
                           : Unresolved text symbol
"ORBit_send_system_exception" -- 1st referenced by=20
                           generated/libbasic.a(basic-skels.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"CORBA_string(float,=20
                           long double,...)(...)" -- 1st referenced by
generated/libbasic.a(basic-skels.o).=20
                           Use linker=20
                           option -v to see when and which objects, archi=
ves
and dsos are loaded.=20
                           ld32: ERROR 33 :=20
                           Unresolved text symbol
"ORBit_send_user_exception" -- 1st referenced by=20
                           generated/libbasic.a(basic-skels.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "PortableServer_ServantBase__init" -- 1st
referenced by=20
                           generated/libbasic.a(basic-skels.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol
"ORBit_register_class" -- 1st referenced by=20
                           generated/libbasic.a(basic-skels.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "PortableServer_ServantBase__fini" -- 1st
referenced by=20
                           generated/libbasic.a(basic-skels.o).=20

                           Use linker option -v to see when and which
objects, archives and dsos are=20
                           loaded.=20
                           ld32: ERROR=20
                           33 : Unresolved text symbol "ORBit_free" -- 1s=
t
referenced by=20
                           generated/libbasic.a(basic-common.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol
"ORBit_alloc" -- 1st=20
                           referenced by
generated/libbasic.a(basic-common.o).=20
                           Use linker option -v to see when and=20
                           which objects, archives and dsos are loaded.=20
                           ld32: ERROR 33 : Unresolved text symbol=20
                           "ORBit_TypeCode_epv" -- 1st referenced by=20
                           generated/libbasic.a(basic-common.o).=20
                           Use=20
                           linker option -v to see when and which objects=
,
archives and dsos are loaded.=20
                           ld32: ERROR 33=20
                           : Unresolved text symbol "TC_long_struct" -- 1=
st
referenced by=20
                           generated/libbasic.a(basic-common.o).=20
                           Use linker option -v to see when and which
objects,=20
                           archives and dsos are loaded.=20
                           ld32: INFO 152: Output file removed because of
error.=20
                           collect2: ld returned 2 exit status=20
                           gmake[1]: *** [client] Error 1=20
                           gmake[1]: Leaving directory=20
                           `/var/tmp/orbitcpp-0.30-pre1/test/basic'=20
                           gmake: *** [all-recursive] Error 1=20


Have I to install other packages or, really, where is the problem?=20

Thank you in advance.
Silicon Graphics, S.A. Sociedad Unipersonal
Plaza del Descubridor Diego de Ord=E1s 3
Tel:+34 91 398 42 00
Edificio Santa Engracia 120
Fax:+34 91 398 42 01
28003 Madrid
E-mail: ob...@ma...
V-mail: 6-368-4273

NB:  INFORMATION IN THIS MESSAGE IS SGI CONFIDENTIAL.  IT IS INTENDED SOL=
ELY
FOR THE PERSON(S) TO WHOM IT IS ADDRESSED AND MAY NOT BE COPIED, USED,
DISCLOSED OR DISTRIBUTED TO OTHERS WITHOUT SGI CONSENT.  IF YOU ARE NOT
THE INTENDED RECIPIENT PLEASE WILL YOU NOTIFY ME BY EMAIL OR TELEPHONE,
DELETE THE MESSAGE FROM YOUR SYSTEM IMMEDIATELY AND DESTROY ANY PRINTED
COPIES.

Re: [orbitcpp-list] orbitcpp SPEC file

[Richard A. <ric...@ix...>]

Thanks for doing that,

That'll come in handy some time soon, I bet.


On Mon, 30 Apr 2001 11:04:25 Dag Wieers wrote:
> Hey,
> 
> Here's a SPEC file for orbitcpp, if you put this into your source-dir
> everyone can easily create a source and binary-package for their system
> using:
> 
> 	rpm -ta target=i686 orbitcpp-0.30.tar.gz
> 
> The reason I use orbitcpp is because drip is using it and since I'm very
> keen on using packages, I made one for you ;)
> 
> Thanks alot for all your work.
> 
> --  dag wieers,  <da...@wi...>,  http://dag.wieers.com/   --
> «Onder voorbehoud van hetgeen niet uitdrukkelijk wordt erkend.»
> 
> 
> Name:		orbitcpp
> Version:	0.30
> Release:	1_dag_1
> Summary:	C++ bindings for the ORBit Corba ORB.
> URL:		http://orbitcpp.sourceforge.net/
> Group:		Development/Libraries
> #Icon:		orbitcpp.png
> Source:		http://prdownloads.sourceforge.net/orbitcpp/%{name}-%{version}.tar.gz
> Copyright:	GPL
> Packager:	Dag Wieers <da...@wi...>
> BuildRoot:	%{_tmppath}/%{name}-%{version}
> Prefix:		%{_prefix}
> 
> %description
> ORBit-C++ is a project to develop C++ bindings for the ORBit Corba
> ORB. ORBit-C++ is Free Software (OpenSource), copyrighted under the
> GPL and LGPL.
> 
> Primary Objectives
>  * Provide a spec-compliant C++ corba mapping for ORBit
>  * To allow programmers to use and write ORBit objects and gnome
>    components in C++ with little or no runtime overhead (compared to
>    writing C ones)
>  * Allow C programmers to use C++ objects without having to deal with
>    any of that 'horrible C++ syntax'
> 
> In short, to C++ programmers, all ORBit objects look like C++ 
> objects, and to C programmers, all ORBit objects should look like C
>  objects.
> 
> Secondary Objectives
>  * Allow C and C++ objects in the same address space to short-circuit
>    calls (i.e. no on-the-wire marshalling) for maximum speed.
> 
> %package devel
> Summary:	C++ bindings for the ORBit Corba ORB.
> Group:		Development/Libraries
> Requires:	orbitcpp
> 
> %description devel
> This packages contains the header files, libraries and utilities
> necessary to write programs that use orbitcpp. If you want to write
> such programs, you'll also need to install the orbitcpp package.
> 
> %prep
> %setup
> 
> %build
> %configure
> make
> 
> %install
> %makeinstall
> 
> %clean
> rm -rf %{buildroot}
> 
> %files
> %defattr(-,root,root)
> %doc AUTHORS ChangeLog COPYING FAQ INSTALL NEWS README README-0.30
> %{_libdir}/*.so*
> 
> %files devel
> %doc HACKING
> %{_bindir}/*
> %{_libdir}/*.a
> %{_libdir}/*.la
> %{_includedir}/orb/*
> %{_datadir}/aclocal/*
> 
> %changelog
> * Mon Apr 30 2001 Dag Wieers <da...@wi...>
> - Initial SPEC-file
> 

[orbitcpp-list] orbitcpp SPEC file

[Dag W. <da...@wi...>]

Hey,

Here's a SPEC file for orbitcpp, if you put this into your source-dir
everyone can easily create a source and binary-package for their system
using:

	rpm -ta target=3Di686 orbitcpp-0.30.tar.gz

The reason I use orbitcpp is because drip is using it and since I'm very
keen on using packages, I made one for you ;)

Thanks alot for all your work.

--  dag wieers,  <da...@wi...>,  http://dag.wieers.com/   --
=ABOnder voorbehoud van hetgeen niet uitdrukkelijk wordt erkend.=BB

Re: [orbitcpp-list] CosNaming.idl compilation problems

[Richard A. <ric...@ix...>]

Looks like your system doesn't compile shared libraries. The c++ back-end
needs to be compiled as a shared library because it has to be dynamically
opened at run time. Make sure you didn't use the the --disable-shared
option for configure.

I had a similar problem using libstdc++-2.90.8 with gcc-2.95.2 because
there was no shared version of libstdc++ (this is probably the problem you
are having as well).

My suggestion is ditch the RH compiler (2.96) and get a CVS version of
gcc-3 and libstdc++-3. There are RPMs and source tarballs at
www.codesourcery.com/gcc-snapshots. They are very stable. I've used these
compilers recently to compile orbitcpp. 
Install into a non-standard location so you don't clobber the existing
system compiler. You're looking at about 5M download for gcc and libstdc++
binary RPMs.

I did this

rpm -i --prefix=/usr/develop gcc-XXX.rpm

And the same with the libstdc++ rpm

Then put /usr/develop at the top of the search path.

You'll also need to set LD_LIBRARYPATH and LD_RUNPATH environment variables
to point to /usr/develop/lib.


Hope this helps

Rich

On Sun, 29 Apr 2001 05:29:03 Ryan Olson wrote:
> Hi,
> 
> I've been trying to compile orbitcpp-0.30 and can't seem to get around 
> the following compile error:
> 
> make[2]: Entering directory `/usr/local/src/orbitcpp-0.30/services/name'
> /usr/bin/orbit-idl -l c++ --backenddir=../../compiler/.libs
> ./CosNaming.idl
> 
> ** WARNING **: Module load failed: 
> ../../compiler/.libs/liborbit-idl-c++-backend.so: cannot open shared 
> object file: No such file or directory
> 
> ** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend): 
> assertion `binfo && binfo->op_output' failed.
> 
> ** WARNING **: ./CosNaming.idl compilation failed
> sed -e 's/#include \"CosNaming\.h\"/#include 
> \"ORBitservices\/CosNaming.h\"/' CosNaming-cpp-common.hh > CosNaming.hh
> 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/src/orbitcpp-0.30/services/name'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/local/src/orbitcpp-0.30/services'
> make: *** [all-recursive] Error 1
> 
> 
> The only files in the compiler/.libs dir are:
> 
> total 4960
> -rw-r--r--    1 root     root      5061762 Apr 28 00:53 
> liborbit-idl-c++-backend.a
> lrwxrwxrwx    1 root     root           30 Apr 28 00:53 
> liborbit-idl-c++-backend.la -> ../liborbit-idl-c++-backend.la
> -rw-r--r--    1 root     root          672 Apr 28 00:53 
> liborbit-idl-c++-backend.lai
> 
> 
> FWIW, I'm using RedHat 7.0 with gcc 2.96, with the ORBit-0.5.7-ximian.3 
> and ORBit-devel-0.5.7-ximian.3 packages.
> 
> Any advice? TIA
> 
> Ryan Olson
> 
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
> 

[orbitcpp-list] CosNaming.idl compilation problems

[Ryan O. <rdo...@pa...>]

Hi,

I've been trying to compile orbitcpp-0.30 and can't seem to get around 
the following compile error:

make[2]: Entering directory `/usr/local/src/orbitcpp-0.30/services/name'
/usr/bin/orbit-idl -l c++ --backenddir=../../compiler/.libs ./CosNaming.idl

** WARNING **: Module load failed: 
../../compiler/.libs/liborbit-idl-c++-backend.so: cannot open shared 
object file: No such file or directory

** CRITICAL **: file orbit-idl-driver.c: line 50 (orbit_idl_to_backend): 
assertion `binfo && binfo->op_output' failed.

** WARNING **: ./CosNaming.idl compilation failed
sed -e 's/#include \"CosNaming\.h\"/#include 
\"ORBitservices\/CosNaming.h\"/' CosNaming-cpp-common.hh > CosNaming.hh
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/src/orbitcpp-0.30/services/name'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/usr/local/src/orbitcpp-0.30/services'
make: *** [all-recursive] Error 1


The only files in the compiler/.libs dir are:

total 4960
-rw-r--r--    1 root     root      5061762 Apr 28 00:53 
liborbit-idl-c++-backend.a
lrwxrwxrwx    1 root     root           30 Apr 28 00:53 
liborbit-idl-c++-backend.la -> ../liborbit-idl-c++-backend.la
-rw-r--r--    1 root     root          672 Apr 28 00:53 
liborbit-idl-c++-backend.lai


FWIW, I'm using RedHat 7.0 with gcc 2.96, with the ORBit-0.5.7-ximian.3 
and ORBit-devel-0.5.7-ximian.3 packages.

Any advice? TIA

Ryan Olson

[orbitcpp-list] Insure++ finds errors in ORBit-cpp

[Jiva D. <ji...@op...>]

Not sure if this is in orbitcpp or in ORBit proper... but the
following report:

Runtime: Executed "TRouteMan.test" on jiva.internal.opnix.com,
pid=32592  [9 tot.]
  Reading overflows memory.
          bbbbbbb
          |  5  | 3 |
                rrrrr
   Reading    (r) : 0x08084605 thru 0x08084607 (3 bytes)
   From block (b) : 0x08084600 thru 0x08084604 (5 bytes)
                   block allocated at:
                        g_malloc()
                  g_get_home_dir()
                 CORBA::ORB_init()  orbitcpp_orb.cc, 45
                      0x08051b31()
                      0x0805086c()
                      0x0805c443()
                      0x080517ac()
               __libc_start_main()
  Stack trace where the error occurred:
                      0x4024e311()
                  g_get_home_dir()
                 CORBA::ORB_init()  orbitcpp_orb.cc, 45
                      0x08051b31()
                      0x0805086c()
                      0x0805c443()
                      0x080517ac()
               __libc_start_main()

shows a read off the end of a buffer in the ORB_init() function.  My
version shows this line number as:

// public functions
-----------------------------------------------------------

CORBA::ORB_ptr CORBA::ORB_init(int& argc, char** argv,const char*
orb_identifier
        CEnvironment ev;
        CORBA_ORB o = CORBA_ORB_init(&argc,
	argv,const_cast<char*>(orb_identifie
        ev.propagate_sysex();
        return reinterpret_cast<ORB_ptr>(o);
}

(yes, word wrap strikes again!) I am using the cvs version of orbit. 

Anyone have any idea what this might be?

-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Simply supersonic bandwidth.
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7

Re: [orbitcpp-list] ORBITCpp cvs broken?

[<MHL...@t-...>]

On Mon, 16 Apr 2001 20:21:09 Jiva DeVoe wrote:
> I get the following errors trying to compile orbitcpp from cvs.  is
> this a known issue?  Do I need to update my compiler or anything?
> 

ORBit defines a special data structure for sequence<any>. However at
least I don't find any functions that work on this data structure
that could be wrapped by orbitcpp. So sequence<any> simply gets
broken by the ORBit-stuff.

Workaround: put a remark or an #if 0 around the lines ...

#define _CORBA_sequence_CORBA_any_defined
typedef struct CORBA_sequence_CORBA_any_struct CORBA_AnySeq;
typedef struct CORBA_sequence_CORBA_any_struct CORBA_sequence_CORBA_any;

.. in ORBit???/src/orb/corba_sequence.h and rebuild / reinstall ORBit.
_CORBA_sequence_CORBA_any_defined is used to disable the c-stubs for
sequence<any>. Remarking the above lines therefore enables the c-stubs
which include the typecode your compiler complains that is missing.

I think I remember Phil having discussed the issue on the ORBit-list
so hopefully in the next version of ORBit this will be fixed.


-- Martin

[orbitcpp-list] ORBit-C++ & ORBit-mt

[Maxim Y. <ma...@fr...>]

I need to compile multithreaded ORBit-C++ version (ORBit-mt based ???).
If somebody was making such version, please help me to do that.

Best regards, Maxim Yevtyushkin.

#-------------------------------#
| Open Linux Technologies, Ltd. |
|       Russia, Moskow          |
#-------------------------------#

[orbitcpp-list] ORBITCpp cvs broken?

[Jiva D. <ji...@op...>]

I get the following errors trying to compile orbitcpp from cvs.  is
this a known issue?  Do I need to update my compiler or anything?

gcc -DHAVE_CONFIG_H -I. -I. -I../../../orb
-I../../.. -I../../.. -I/usr/lib/glib/include -I/usr/include     -g
-O0 -Wall -W -c everything-common.c
everything-common.c:666: `TC_CORBA_sequence_CORBA_any_struct'
undeclared here (not in a function)
everything-common.c:666: initializer element is not constant
everything-common.c:666: (near initialization for
`anon_subtypes_array128[0]')
everything-common.c: In function `test_FixedLengthStruct__free':
everything-common.c:2842: warning: unused parameter `dat'
everything-common.c:2843: warning: unused parameter `free_strings'
everything-common.c: In function `test_VariableLengthStruct__free':
everything-common.c:2863: warning: unused parameter `dat'
everything-common.c: In function `test_CompoundStruct__free':
everything-common.c:2888: warning: unused parameter `dat'
everything-common.c: In function `CORBA_sequence_CORBA_string__free':
everything-common.c:2928: warning: unused parameter `dat'
everything-common.c: In function
`CORBA_sequence_test_CompoundStruct__free':
everything-common.c:2993: warning: unused parameter `dat'
everything-common.c: In function `CORBA_sequence_CORBA_long__free':
everything-common.c:3060: warning: unused parameter `dat'
everything-common.c: In function `CORBA_sequence_test_StrSeq__free':
everything-common.c:3187: warning: unused parameter `dat'
everything-common.c: In function `test_AnySeq__free':
everything-common.c:3294: warning: implicit declaration of function
`CORBA_sequence_CORBA_any__free'
everything-common.c:3294: warning: return makes pointer from integer
without a cast
everything-common.c: In function `test_AnySeq__alloc':
everything-common.c:3300: warning: implicit declaration of function
`CORBA_sequence_CORBA_any__alloc'
everything-common.c:3300: warning: return makes pointer from integer
without a cast
everything-common.c: In function `test_StructWithSequenceInIt__free':
everything-common.c:3357: warning: unused parameter `dat'
everything-common.c: In function `test_TestException__free':
everything-common.c:3435: warning: unused parameter `dat'
everything-common.c: In function `test_TestStruct2__free':
everything-common.c:3468: warning: unused parameter `dat'
everything-common.c: In function `test_TestException2__free':
everything-common.c:3492: warning: unused parameter `dat'
everything-common.c: In function `test_LongArray__free':
everything-common.c:3517: warning: unused parameter `dat'
everything-common.c:3517: warning: unused parameter `free_strings'

-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Simply awesome bandwidth.
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7

Re: [orbitcpp-list] A possible bug?

[Jiva D. <ji...@op...>]

Thanks. :)

On Fri, Apr 06, 2001 at 06:00:17PM +0100, Phil Dawes wrote:
Content-Description: message body text
> Hi Jiva,
> 
> Fixed it.
> 
> The bug is in ORBit-0.5 orb ref counting. I've attached a patch to
> ORBit which fixes this. I'll commit it to ORBit CVS so that it will be
> in the next release.
> 



-- 
Jiva DeVoe
VP Of Software Development
Opnix, Inc. - Simply makes-you-wanna-cry-for-mercy bandwidth.
GPG Fingerprint: 0A17 DF84 516A 1DC4 B837  FE6D 3128 41CD 97CB 4AA7

Re: [orbitcpp-list] ORBit-mt integration

[Sam C. <sa...@to...>]

Konrad Podloucky <ko...@cr...> wrote:
> Hi folks,
> 
> I've been playing around with ORBit-mt a bit and I'd thought it
> would be nice, if orbitcpp would check for ORBit-mt in the
> autoconf script and enable a '--multithread' option in
> orbitcpp-config (which would call orbit-config-mt with the
> appropriate options).
> If nobody objects, I'd have a go at this.

Try these patches for a starting point. I never got around to making them
all that nice, just made them look like they work.
-- 
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

[orbitcpp-list] ORBit-mt integration

[Konrad P. <ko...@cr...>]

Hi folks,

I've been playing around with ORBit-mt a bit and I'd thought it
would be nice, if orbitcpp would check for ORBit-mt in the
autoconf script and enable a '--multithread' option in
orbitcpp-config (which would call orbit-config-mt with the
appropriate options).
If nobody objects, I'd have a go at this.

Cheers,
        Konrad

________________________________________________________________
  .~.   Konrad Podloucky      GnuPG/PGP-key available by request
  /V\    Why Bill Gates has succeeded:
 // \\     "The obvious mathematical breakthrough would be 
/(   )\     development of an easy way to factor large prime   
 ^^-^^      numbers." The Road Ahead (1995), page 265

Re: [orbitcpp-list] A possible bug?

[Phil D. <ph...@us...>]

Hi Jiva,

Fixed it.

The bug is in ORBit-0.5 orb ref counting. I've attached a patch to
ORBit which fixes this. I'll commit it to ORBit CVS so that it will be
in the next release.

Cheers,

Phil

Re: [orbitcpp-list] A possible bug?

[Phil D. <ph...@us...>]

Hi Jiva,

In fact this code shouldn't work anyway, since you are using an _var
type to hold the orb, which is a smartpointer and will release the old
orb ref when reassigned to. This means that in your example the orb
ref is released twice.

The problem is that this code still segfaults if a CORBA::ORB_ptr is
used, and that is most likely an orbit bug somewhere. I'll check this
out.

Cheers,

Phil

Jiva DeVoe writes:
 > The following code causes a segfault on the second one.  Why?
 > 
 > CORBA::ORB_var orb; 
 >   cout << "1" << endl; 
 >   orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
 >   CORBA::release(orb); 
 >   cout << "1" << endl; 
 >   orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
 >   CORBA::release(orb); 
 >   cout << "1" << endl; 
 >   orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
 >   CORBA::release(orb); 
 >   cout << "1" << endl; 
 >   orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
 >   CORBA::release(orb); 
 >   cout << "1" << endl; 
 >   orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
 >   CORBA::release(orb); 
 > 
 > Some folks wouldn't do this, but we have unit tests that need to setup
 > and tear down a corba connection for serveral consecutive tests.  This
 > crashes my code.
 > -- 
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list

[orbitcpp-list] A possible bug?

[Jiva D. <ji...@op...>]

The following code causes a segfault on the second one.  Why?

CORBA::ORB_var orb; 
  cout << "1" << endl; 
  orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
  CORBA::release(orb); 
  cout << "1" << endl; 
  orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
  CORBA::release(orb); 
  cout << "1" << endl; 
  orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
  CORBA::release(orb); 
  cout << "1" << endl; 
  orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
  CORBA::release(orb); 
  cout << "1" << endl; 
  orb = CORBA::ORB_init(argc, argv, "orbit-local-orb"); 
  CORBA::release(orb); 

Some folks wouldn't do this, but we have unit tests that need to setup
and tear down a corba connection for serveral consecutive tests.  This
crashes my code.
-- 

[orbitcpp-list] Memory leak warning

[Phil D. <ph...@us...>]

Hi All,

I've been fixing memory leaks over the last few weeks (there were
quite a few, both in ORBit and orbitcpp.

The upshot is that if you are likely to be using orbitcpp in a
long-running server capacity any time soon, you really need to use the
CVS versions of ORBit and orbitcpp.

Currently there remains 2 leaks AFAIK.

1: with transient objects using _add_ref() and _remove_ref(). 
-------------------------------------------------------------

This is because orbit-0.5 isn't calling the object finalizer, which
deals with the refcounting. (this works with ORBit-head and ORBit2 - I
will work with the orbit team to fix this.)

2: typecodes passed as inout parameters
---------------------------------------

I am investigating this now.



Cheers,

Phil

Re: [orbitcpp-list] Re: Module split between 2 files causes internal compiler error

[Phil D. <ph...@us...>]

Hi Kuba,

I've fixed this in CVS now. Thanks for a fantastic diagnosis!

Cheers,

Phil


Kuba writes:
 > Maybe this will save You some work:
 > Look into IDLElement constructor (language.cc file). It appears that IDL_tree that comes from orbit-idl contains two separate elements for "A" module (one for file2.idl and one for included file1.idl). During gather pass the first module (that from file1.idl) is analyzed and inserted into orbitcpp tree correctly, but the second one (from file2.idl) is seen in IDLElement constructor as declaration that replaces forward declaration. This messes things up in xlate pass, when orbitcpp tree node is searched for IDL_tree element containing description of file1.idl "A" module, which was removed in gather pass.
 > 
 > Best regards,
 > Kuba
 > 
 > >Send orbitcpp-list mailing list submissions to
 > > orb...@li...
 > > 
 > > To subscribe or unsubscribe via the World Wide Web, visit
 > > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
 > > or, via email, send a message with subject or body 'help' to
 > > orb...@li...
 > > 
 > > You can reach the person managing the list at
 > > orb...@li...
 > > 
 > > When replying, please edit your Subject line so it is more specific
 > > than "Re: Contents of orbitcpp-list digest..."
 > > 
 > > 
 > > Today's Topics:
 > > 
 > >    1. Re: Module split between 2 files causes internal compiler error (Phil Dawes)
 > > 
 > > --__--__--
 > > 
 > > Message: 1
 > > From: "Phil Dawes" <ph...@us...>
 > > Date: Tue, 3 Apr 2001 10:27:24 +0100 (BST)
 > > To: orb...@li...
 > > Subject: Re: [orbitcpp-list] Module split between 2 files causes internal compiler error
 > > Reply-To: orb...@li...
 > > 
 > > Hi Kuba,
 > > 
 > > I can reproduce this problem with CVS orbitcpp. I'll try and have a
 > > look at it tonight.
 > > 
 > > Cheers,
 > > 
 > > Phil
 > > 
 > > Kuba writes:
 > >  > The following situation causes orbitcpp to generate internal error (ORBit 0.5.7 works fine).
 > >  > I have 2 files in the same directory:
 > >  > file1.idl:
 > >  > ---------------
 > >  > module A {
 > >  > interface Unrelevant1 {
 > >  > };
 > >  > };
 > >  > ---------------
 > >  > file2.idl:
 > >  > ---------------
 > >  > #include <file1.idl>
 > >  > module A {
 > >  > interface Unrelevant2 {
 > >  > };
 > >  > };
 > >  > ---------------
 > >  > Then:
 > >  > orbit-idl -l c++ -I. file2.idl
 > >  > 
 > >  > Internal error.
 > >  > I tried to track this, but orbitcpp code is still too sophisticated for me :(
 > >  > 
 > >  > Kuba
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > 
 > >  > -- 
 > >  >  
 > >  > 
 > >  > _______________________________________________
 > >  > orbitcpp-list mailing list
 > >  > orb...@li...
 > >  > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
 > > 
 > > 
 > > 
 > > 
 > > --__--__--
 > > 
 > > _______________________________________________
 > > orbitcpp-list mailing list
 > > orb...@li...
 > > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
 > > 
 > > 
 > > End of orbitcpp-list Digest
 > > 
 > > 
 > 
 > 
 > 
 > -- 
 >  
 > 
 > _______________________________________________
 > orbitcpp-list mailing list
 > orb...@li...
 > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list

[orbitcpp-list] Re: Module split between 2 files causes internal compiler error

[Kuba <kp...@po...>]

Maybe this will save You some work:
Look into IDLElement constructor (language.cc file). It appears that IDL_tree that comes from orbit-idl contains two separate elements for "A" module (one for file2.idl and one for included file1.idl). During gather pass the first module (that from file1.idl) is analyzed and inserted into orbitcpp tree correctly, but the second one (from file2.idl) is seen in IDLElement constructor as declaration that replaces forward declaration. This messes things up in xlate pass, when orbitcpp tree node is searched for IDL_tree element containing description of file1.idl "A" module, which was removed in gather pass.

Best regards,
Kuba

>Send orbitcpp-list mailing list submissions to
> orb...@li...
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
> or, via email, send a message with subject or body 'help' to
> orb...@li...
> 
> You can reach the person managing the list at
> orb...@li...
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of orbitcpp-list digest..."
> 
> 
> Today's Topics:
> 
>    1. Re: Module split between 2 files causes internal compiler error (Phil Dawes)
> 
> --__--__--
> 
> Message: 1
> From: "Phil Dawes" <ph...@us...>
> Date: Tue, 3 Apr 2001 10:27:24 +0100 (BST)
> To: orb...@li...
> Subject: Re: [orbitcpp-list] Module split between 2 files causes internal compiler error
> Reply-To: orb...@li...
> 
> Hi Kuba,
> 
> I can reproduce this problem with CVS orbitcpp. I'll try and have a
> look at it tonight.
> 
> Cheers,
> 
> Phil
> 
> Kuba writes:
>  > The following situation causes orbitcpp to generate internal error (ORBit 0.5.7 works fine).
>  > I have 2 files in the same directory:
>  > file1.idl:
>  > ---------------
>  > module A {
>  > interface Unrelevant1 {
>  > };
>  > };
>  > ---------------
>  > file2.idl:
>  > ---------------
>  > #include <file1.idl>
>  > module A {
>  > interface Unrelevant2 {
>  > };
>  > };
>  > ---------------
>  > Then:
>  > orbit-idl -l c++ -I. file2.idl
>  > 
>  > Internal error.
>  > I tried to track this, but orbitcpp code is still too sophisticated for me :(
>  > 
>  > Kuba
>  > 
>  > 
>  > 
>  > 
>  > 
>  > -- 
>  >  
>  > 
>  > _______________________________________________
>  > orbitcpp-list mailing list
>  > orb...@li...
>  > http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
> 
> 
> 
> 
> --__--__--
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
> 
> 
> End of orbitcpp-list Digest
> 
> 



--