orbitcpp-list

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

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

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] Module split between 2 files causes internal compiler error

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

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





-- 
 

Re: [orbitcpp-list] Extend test everything to find&fix bgus

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

Bug fix update!


Martin Schulze writes:
 > 
 > 
 > - "TestException ex; CORBA::Any any; any <<= ex;" segfaults :-(
 > 


This is because Exceptions in orbitcpp aren't binary compatible with C
exceptions (because the c++ version has a vtable). The insertion code
attempts to treat it as such.

Working out a fix now...

Cheers,

Phil

Re: [orbitcpp-list] Extend test everything to find&fix bgus

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

Hi Martin,

Thanks for submitting these. I've sent a patch to fix the first one to
the ORBit crowd (I'm waiting for objections from the ORBit crowd
before I commit).

I'm now working on the 2nd.

Sorry for not responding sooner.

Cheers,

Phil


Martin Schulze writes:
 > Hi!
 > 
 > I currecntly have three open bugs in orbit/orbitcpp:
 > 
 > - sequence<any> doesn't compile
 > 
 >   Workaround: remark the following lines in orb/corba_sequence.h
 > 
 >   /*#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;*/
 > 
 > 
 > - "TestException ex; CORBA::Any any; any <<= ex;" segfaults :-(
 > 
 > - "Transient Object Test" segfaults when orbitcpp is compiled against
 > ORBit-mt
 > 
 > 
 > I propose the attached patch to test everything to discover the bugs.
 > Anyone fixing those is warmly welcome ...
 > 
 > 
 > Cu,
 > 
 >   Martin

[orbitcpp-list] Error in String_var

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

I think, that I found an error in String_var class in orbitcpp_smartptr.hh. According to Corba 2.2 spec _retn () method should detach String_var object from contained string and return it. All other *_var classes in orbitcpp_smartptr.hh behave that way, except String_var. I think, that Properties::free () call is unneccesary.

Kuba

[orbitcpp-list] Extend test everything to find&fix bgus

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

Hi!

I currecntly have three open bugs in orbit/orbitcpp:

- sequence<any> doesn't compile

  Workaround: remark the following lines in orb/corba_sequence.h

  /*#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;*/


- "TestException ex; CORBA::Any any; any <<= ex;" segfaults :-(

- "Transient Object Test" segfaults when orbitcpp is compiled against
ORBit-mt


I propose the attached patch to test everything to discover the bugs.
Anyone fixing those is warmly welcome ...


Cu,

  Martin

[orbitcpp-list] more bugs with sequences

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

Hi!

I experienced another two bugs that have to do with
sequences:

- In a function of an interface I copy a sequence and
  return it to the client. If the sequence has zero
  length the client's call to the c-stub-function returns
  0x0 and a some Systemexception. The program then
  segfaults in the exception handler. E.g.:

  module test {
    struct bar {
      long id;
      string descr;
    }
    typedef sequence<bar> foo;

    interface hello {
      foo say_hello();
    };
  }

  and:

  test::hello::hello() {
  }
  test::foo* test::hello::say_hello() {
    test::foo foo1;
    foo1.length(0); // Only if the length is zero, the error occurs
    test::foo* foo2 = new foo;
    *foo2 = foo1;
    return foo2;  // foo2 is returned but the client receives 0x0
                  // and a Systemexception; the stub-function never
                  // returns, though; the program segfaults !
  }


- I find it impossible to copy a struct that holds
  a sequence<double> - this time an exception is thrown
  in libstdc++. The struct looks as follows:

  module test {
    struct bar1_t {
      short s1;
      short s2;
      short s3;
    };
    typedef sequence<double> bar2_t;

    struct foo {
      bar1_t bar1;
      bar2_t bar2;
    };
  }

  The code that faults is:

  void doTest() {
    test::foo foo1;
    foo1.bar2.length(1);
    test::foo foo2( foo1 );  // exception thrown in some
corba-copy-function
  }


I will do some debugging if nobody knows a solution
to these. Have to get a newer version of gcc and gdb
first; gcc 2.95.2 with gdb 4.18-4 is a horror if you
work with shared libraries :-(

Cu,

  Martin

Re: [orbitcpp-list] Re: orbitcpp-list digest, Vol 1 #177 - 1 msg

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

Hi all!

Since I didn't get a response to my last mail, here is my second try:
The attached patch just inserts one line into file pass_xlate.cc that
causes the any inserters and hmhm (language problem: hmhm=opposite of
inserter :-)) for structs and interfaces to be placed in the namespace
of the module. This was the case in orbitcpp 0.29 and I suppose this
is correct. Putting them into the global namespace as orbitcpp 0.30
does at the moment, seems totally unlogical for my compiler and me.
Unfortunately I have no idea where to look up the specs quick and
what the specs say about my problem. Again please anybody who knows:
please check the patch first.

Have fun,

  Martin.



On Don, 08 Mär 2001 11:50:47 Martin Schulze wrote:
> On Don, 08 Mär 2001 00:09:39 John Luebs wrote:
> > 
> > > Message: 1
> > > Date: Wed, 7 Mar 2001 14:23:46 +0100
> > > From: MHL...@t-... (Martin Schulze)
> > > To: orb...@li...
> > > Subject: Re: [orbitcpp-list] support for sequence<any> broken in
> > orbitcpp-0.30
> > > Reply-To: orb...@li...
> >  [...]
> > > inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr*
> > val) {
> > >         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > > val, CORBA_FALSE);
> > > }
> > > 
> > > inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr
> val)
> > {
> > >         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > > &val);
> > > }
> > > 
> > > inline CORBA::Boolean operator>>=(const CORBA::Any& the_any,
> > > ::CorbaSigC::Slot_ptr& val) {
> > >         return the_any.extract(
(CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > > val);
> > > }
> > > [...] 
> > > I attached a simple patch for orbitcpp-0.30 that lets
> > > orbitcpp create the latter code. Please check whether it's
> > > okay and if so feel free to commit to cvs.
> > > 
> > > Cu,
> > > 
> > >   Martin.
> > > 
> > 
> > Hey everybody.
> > About a month ago I took a job with Handheld Products, A Welch Allyn
> > Affiliate so with that and personal issues I have been unable to do
> > anything with orbitcpp :-(. 
> > Anyway, I believe the code as it stands is correct. Referring to page
> > 1-52 to 1-54 of the CORBA C++ spec, there must be a copying and a
> > non-copying form of inserter. The non-copying form means that the Any
> > assumes ownership of the object reference, or structure, and the caller
> > of the inserter should not use the structure ever again, so this
> implies
> > the use of
> > a non-const pointer. In fact, an Any implementation can destroy the
> > passed structure and recreate it somewhere else if it so desires.
> > Making this emit const* would violate compliance I believe.
> > 
> > John
> > 
> 
> Oh I'm sorry. Of course the specs always win ... DON'T APPLY THE PATCH !
> 
> What do the specs say about the namespace the inserters should be
> in or not ? My compiler doesn't find them when I try to use them
> implicitly inside the namespace I think they belong, i.e. the module
> the structures/interfaces are defined in. I simply can't imagine that
> they have to be in the global namespace ?!
> 
> Cu,
> 
>   Martin
> 
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/lists/listinfo/orbitcpp-list
> 

Re: [orbitcpp-list] Re: orbitcpp-list digest, Vol 1 #177 - 1 msg

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

On Don, 08 Mär 2001 00:09:39 John Luebs wrote:
> 
> > Message: 1
> > Date: Wed, 7 Mar 2001 14:23:46 +0100
> > From: MHL...@t-... (Martin Schulze)
> > To: orb...@li...
> > Subject: Re: [orbitcpp-list] support for sequence<any> broken in
> orbitcpp-0.30
> > Reply-To: orb...@li...
>  [...]
> > inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr*
> val) {
> >         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > val, CORBA_FALSE);
> > }
> > 
> > inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr val)
> {
> >         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > &val);
> > }
> > 
> > inline CORBA::Boolean operator>>=(const CORBA::Any& the_any,
> > ::CorbaSigC::Slot_ptr& val) {
> >         return the_any.extract( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> > val);
> > }
> > [...] 
> > I attached a simple patch for orbitcpp-0.30 that lets
> > orbitcpp create the latter code. Please check whether it's
> > okay and if so feel free to commit to cvs.
> > 
> > Cu,
> > 
> >   Martin.
> > 
> 
> Hey everybody.
> About a month ago I took a job with Handheld Products, A Welch Allyn
> Affiliate so with that and personal issues I have been unable to do
> anything with orbitcpp :-(. 
> Anyway, I believe the code as it stands is correct. Referring to page
> 1-52 to 1-54 of the CORBA C++ spec, there must be a copying and a
> non-copying form of inserter. The non-copying form means that the Any
> assumes ownership of the object reference, or structure, and the caller
> of the inserter should not use the structure ever again, so this implies
> the use of
> a non-const pointer. In fact, an Any implementation can destroy the
> passed structure and recreate it somewhere else if it so desires.
> Making this emit const* would violate compliance I believe.
> 
> John
> 

Oh I'm sorry. Of course the specs always win ... DON'T APPLY THE PATCH !

What do the specs say about the namespace the inserters should be
in or not ? My compiler doesn't find them when I try to use them
implicitly inside the namespace I think they belong, i.e. the module
the structures/interfaces are defined in. I simply can't imagine that
they have to be in the global namespace ?!

Cu,

  Martin

[orbitcpp-list] Re: orbitcpp-list digest, Vol 1 #177 - 1 msg

[John L. <jk...@lu...>]

> Message: 1
> Date: Wed, 7 Mar 2001 14:23:46 +0100
> From: MHL...@t-... (Martin Schulze)
> To: orb...@li...
> Subject: Re: [orbitcpp-list] support for sequence<any> broken in orbitcpp-0.30
> Reply-To: orb...@li...
 [...]
> inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr* val) {
>         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> val, CORBA_FALSE);
> }
> 
> inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr val) {
>         the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> &val);
> }
> 
> inline CORBA::Boolean operator>>=(const CORBA::Any& the_any,
> ::CorbaSigC::Slot_ptr& val) {
>         return the_any.extract( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
> val);
> }
> [...] 
> I attached a simple patch for orbitcpp-0.30 that lets
> orbitcpp create the latter code. Please check whether it's
> okay and if so feel free to commit to cvs.
> 
> Cu,
> 
>   Martin.
> 

Hey everybody.
About a month ago I took a job with Handheld Products, A Welch Allyn
Affiliate so with that and personal issues I have been unable to do
anything with orbitcpp :-(. 
Anyway, I believe the code as it stands is correct. Referring to page
1-52 to 1-54 of the CORBA C++ spec, there must be a copying and a
non-copying form of inserter. The non-copying form means that the Any
assumes ownership of the object reference, or structure, and the caller
of the inserter should not use the structure ever again, so this implies
the use of
a non-const pointer. In fact, an Any implementation can destroy the
passed structure and recreate it somewhere else if it so desires.
Making this emit const* would violate compliance I believe.

John

Re: [orbitcpp-list] support for sequence<any> broken in orbitcpp-0.30

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

On Sam, 03 Mär 2001 18:02:50 Martin Schulze wrote:
> Hi!
> 
> orbitcpp-0.30 works just perfectly with orbit-0.5.7
> (good work !) but mayby you also want to tackle down this:
> 
> - It doesn't build on top of orbit-mt-0.5.7:
> [snip]

Okay so this works with Sam's patches applied, except that
test 'everything' fails at 'transient object destruction'.


> - The support for predefined CORBA-sequences is broken:
> 
>   Try to compile the output 'orbit-idl -lc++' produces
>   from the following idl-code:
> 
>   module CorbaSigC
>   {
>     typedef sequence<any> ParamList;
> 
>     interface Slot {
>       any call( in ParamList params );
>     };
>   };
> 

A simple workaround for this problem, as I now found out,
is to put a remark around three lines in orb/corba_sequences.h:

[...]
/*#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;*/
[...]


Another problem I experienced with orbitcpp-0.30 lies in the
declaration of the i/o-operators for CORBA::Any that are created
in [name]-cpp-common.hh when you define a struct or interface in
[name]-idl:

For the above example orbit-idl -lc++ would create in
CorbaSigC-cpp-common.hh:

[...]
inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr* val) {
	the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
val, CORBA_FALSE);
}

inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr val) {
	the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
&val);
}

inline CORBA::Boolean operator>>=(const CORBA::Any& the_any,
::CorbaSigC::Slot_ptr& val) {
	return the_any.extract( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
val);
}
[...]

but it has to be something like:

[...]
namespace CorbaSigC {
	inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr
const * val) {  // <---- const Pointer !!!
		the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
val, CORBA_FALSE);
	}

	inline void operator<<=(CORBA::Any& the_any, ::CorbaSigC::Slot_ptr
val) {
		the_any.insert_simple( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
&val);
	}

	inline CORBA::Boolean operator>>=(const CORBA::Any& the_any,
::CorbaSigC::Slot_ptr& val) {
		return the_any.extract( (CORBA::TypeCode_ptr)&::_orbitcpp::c::TC_CorbaSigC_Slot_struct,
val);
	}
}
[...]


I attached a simple patch for orbitcpp-0.30 that lets
orbitcpp create the latter code. Please check whether it's
okay and if so feel free to commit to cvs.


Cu,

  Martin.

Re: [orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

On Mon, 05 Mär 2001 15:48:19 Sam Couter wrote:
> Martin Schulze <MHL...@t-...> wrote:
> > 
> > First I found out that you didn't correct one mistake in configure,
> > line 2524 where it should be:
> > 
> > if $ORBIT_IDL --help | grep -q backenddir; then
> > 
> > instead of
> > 
> > if orbit-idl --help | grep -q backenddir; then
> > 
> > Could you please rebuild mt.diff to include that?
> > (I didn't save my original files...)
> 
> I didn't edit configure, just configure.in and acinclude.m4. After you
> apply
> the patch, run 'aclocal', and with any luck your configure script will be
> fixed.

Ouch, I didn't look at the patch close enough.

> 
> > Still I got loads of errors running configure. Finally I saw the
> > problem: Orbit-mt doesn't include a name-service. So the variables
> > ORBIT_NAME_LIBS and ORBIT_NAME_CFLAGS aren't set correctly and
> > configure fails. I patched my local Orbit-mt to compile and install
> > the name-service from Orbit-0.5.7 under a new name and now at least
> > orbitcpp compiles and installs properly.
> 
> Sebastian Wilhelmi, the ORBit-mt maintainer, said he was going to put
> some
> notes about this on the web page, but it doesn't look like he has.
> 
> I'll attach a patch for ORBit-mt which provides a name service. Like I
> told
> Sebastian when I sent this to him, I don't know how well it really works.
> My
> testing was pretty basic because I don't use the naming service.
> The patch causes make to use orbit-idl-mt to generate the naming stubs,
> build
> a library with them, then link it against libORBitCosNaming.so. That
> means
> you'll have to have ORBit 0.5.7 installed as well as ORBit-mt.
> I had to patch orbit-config-mt.in as well, so the '--use-service=name'
> option works.
> 
> You'll need to re-run "automake; ./configure; make" in ORBit-mt after
> applying
> the patch.
> 

Okay, that's basically the same I did. The only difference: I copied
the existing naming service from ORBit-0.5.7 and changed the names
of the idl-compiler, deps and targets in the make system.


> > However the tests fail:
> [ snip ]
> > multiple definition of `ORBit_default_principal'
> > client.o:/home/martin/buildlibs/orbitcpp-0.30/test/basic/../../orb/orbitcpp_sequence.hh:144:
> > first defined here
> [ snip ]
> > The ouput from compiling test 'everything' is similar.
> > So obviously there is a problem with ORBit_default_principal.
> > I hope you have an idea what that is about.
> 
> I do. The ORBit-mt web page at http://goethe.ira.uka.de/~wilhelmi/ORBit-mt/
> has a note about this and directions to fix it. If you apply the patch I
> mentioned previously, this will already be fixed.

Ah, a missing "extern" - I see!


Okay, now everthing - including 'everything' - compiles smoothly.

Only one problem is left now:

martin@fritz-tower:~/buildlibs/orbitcpp-0.30/test/everything > ./server &
[1] 17463
martin@fritz-tower:~/buildlibs/orbitcpp-0.30/test/everything > ./client 
Testing constants...
1234.56==1234.56
Testing string...
Testing long...
Testing attribute...
Testing exception...
Testing long...
Testing enum...
Testing fixed length structs...
Testing variable length structs...
Testing compound structs...
Testing unbounded sequences...
Testing bounded sequences...
Testing Multiple inheritance polymorphism...
Testing Fixed length element array...
Testing Variable length element array...
Testing transient object destruction...
Speicherzugriffsfehler


After that, I'm back to my problem compiling sequence<any> as the
idl-c++-backend still takes ::_orbitcpp::c::CORBA_sequence_CORBA_any
for granted ...


Thanks so far for your help,

  Martin

Re: [orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

Martin Schulze <MHL...@t-...> wrote:
> 
> First I found out that you didn't correct one mistake in configure,
> line 2524 where it should be:
> 
> if $ORBIT_IDL --help | grep -q backenddir; then
> 
> instead of
> 
> if orbit-idl --help | grep -q backenddir; then
> 
> Could you please rebuild mt.diff to include that?
> (I didn't save my original files...)

I didn't edit configure, just configure.in and acinclude.m4. After you apply
the patch, run 'aclocal', and with any luck your configure script will be
fixed.

> Still I got loads of errors running configure. Finally I saw the
> problem: Orbit-mt doesn't include a name-service. So the variables
> ORBIT_NAME_LIBS and ORBIT_NAME_CFLAGS aren't set correctly and
> configure fails. I patched my local Orbit-mt to compile and install
> the name-service from Orbit-0.5.7 under a new name and now at least
> orbitcpp compiles and installs properly.

Sebastian Wilhelmi, the ORBit-mt maintainer, said he was going to put some
notes about this on the web page, but it doesn't look like he has.

I'll attach a patch for ORBit-mt which provides a name service. Like I told
Sebastian when I sent this to him, I don't know how well it really works. My
testing was pretty basic because I don't use the naming service.
The patch causes make to use orbit-idl-mt to generate the naming stubs, build
a library with them, then link it against libORBitCosNaming.so. That means
you'll have to have ORBit 0.5.7 installed as well as ORBit-mt.
I had to patch orbit-config-mt.in as well, so the '--use-service=name'
option works.

You'll need to re-run "automake; ./configure; make" in ORBit-mt after applying
the patch.

> However the tests fail:
[ snip ]
> multiple definition of `ORBit_default_principal'
> client.o:/home/martin/buildlibs/orbitcpp-0.30/test/basic/../../orb/orbitcpp_sequence.hh:144:
> first defined here
[ snip ]
> The ouput from compiling test 'everything' is similar.
> So obviously there is a problem with ORBit_default_principal.
> I hope you have an idea what that is about.

I do. The ORBit-mt web page at http://goethe.ira.uka.de/~wilhelmi/ORBit-mt/
has a note about this and directions to fix it. If you apply the patch I
mentioned previously, this will already be fixed.
-- 
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

Re: [orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

On Son, 04 Mär 2001 23:19:51 Sam Couter wrote:
> Martin Schulze <MHL...@t-...> wrote:
> > 
> > Ah those attachments, they always seem to get lost :-)
> > Could you please try to send the patches again ?
> 
> Heh... Maybe I forgot to attach them. Wouldn't be the first time I've
> done
> that. ;)

No problem ...


Anyway, I was not all successful :-(

First I found out that you didn't correct one mistake in configure,
line 2524 where it should be:

if $ORBIT_IDL --help | grep -q backenddir; then

instead of

if orbit-idl --help | grep -q backenddir; then

Could you please rebuild mt.diff to include that?
(I didn't save my original files...)

Still I got loads of errors running configure. Finally I saw the
problem: Orbit-mt doesn't include a name-service. So the variables
ORBIT_NAME_LIBS and ORBIT_NAME_CFLAGS aren't set correctly and
configure fails. I patched my local Orbit-mt to compile and install
the name-service from Orbit-0.5.7 under a new name and now at least
orbitcpp compiles and installs properly.


However the tests fail:

The output from compiling test 'basic' is as follows:

Making all in generated
make[1]: Entering directory `/home/martin/buildlibs/orbitcpp-0.30/test/basic/generated'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/home/martin/buildlibs/orbitcpp-0.30/test/basic/generated'
make[1]: Entering directory `/home/martin/buildlibs/orbitcpp-0.30/test/basic'
/bin/sh ../../libtool --mode=link c++  -g -Wall  -o client  client.o
./../orb/liborbitcpp.la -L/opt/orbit/lib -L/usr/lib -lORBit-mt -lIIOP-mt
-lORBitutil-mt -lgthread -lglib -lpthread -lpopt -lm -lm
generated/libbasic.a  
c++ -g -Wall -o .libs/client client.o ../../orb/.libs/liborbitcpp.so
-L/opt/orbit/lib -L/usr/lib -lORBit-mt -lIIOP-mt -lORBitutil-mt -lgthread
-lglib -lpthread -lpopt -lm -lstdc++ -L/opt/orbit/lib -L/usr/lib -lORBit-mt
-lIIOP-mt -lORBitutil-mt -lgthread -lglib -lpthread -lpopt -lm -lm
generated/libbasic.a -Wl,--rpath -Wl,/opt/orbit/lib
generated/libbasic.a(basic-cpp.o): In function
`Test::Scoping::Failure::_orbitcpp_pack(void)':
/home/martin/buildlibs/orbitcpp-0.30/test/basic/generated/../../../orb/orbitcpp_exception.hh(.bss+0x0):
multiple definition of `ORBit_default_principal'
client.o:/home/martin/buildlibs/orbitcpp-0.30/test/basic/../../orb/orbitcpp_sequence.hh:144:
first defined here
collect2: ld returned 1 exit status
make[1]: *** [client] Error 1
make[1]: Leaving directory `/home/martin/buildlibs/orbitcpp-0.30/test/basic'
make: *** [all-recursive] Error 1


The ouput from compiling test 'everything' is similar.
So obviously there is a problem with ORBit_default_principal.
I hope you have an idea what that is about.


Cu,

  Martin

Re: [orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

Martin Schulze <MHL...@t-...> wrote:
>=20
> Ah those attachments, they always seem to get lost :-)
> Could you please try to send the patches again ?

Heh... Maybe I forgot to attach them. Wouldn't be the first time I've done
that. ;)

Here's a second try.
--=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

Re: [orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

On Son, 04 Mär 2001 01:50:03 Sam Couter wrote:
> To whomever was trying to build ORBit-C++ against ORBit-mt 0.5.7,
> 
> Try these attached patches. They might still be a bit rough, I haven't
> had
> time to clean them up and implement this stuff properly.
> 

Ah those attachments, they always seem to get lost :-)
Could you please try to send the patches again ?

> Run the configure script something like:
> 
> ORBIT_IDL="/usr/bin/orbit-idl-mt"

Thanks, I didn't find this ...
Still, without your patches of course, I get the errors with configure.

> ORBIT_CONFIG="/usr/bin/orbit-config-mt"
> \
>         orbit_config_args="--multithread server" ./configure
> 
> Let me know how you go, as I'd like to put the extra debugging and
> testing
> opportunity to good use. :)

I will ...

Cu,

  Martin

[orbitcpp-list] Building ORBit-C++ against ORBit-mt

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

To whomever was trying to build ORBit-C++ against ORBit-mt 0.5.7,

Try these attached patches. They might still be a bit rough, I haven't had
time to clean them up and implement this stuff properly.

Run the configure script something like:

ORBIT_IDL=3D"/usr/bin/orbit-idl-mt" ORBIT_CONFIG=3D"/usr/bin/orbit-config-m=
t" \
        orbit_config_args=3D"--multithread server" ./configure

Let me know how you go, as I'd like to put the extra debugging and testing
opportunity to good use. :)
--=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

[orbitcpp-list] support for sequence<any> broken in orbitcpp-0.30

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

Hi!

orbitcpp-0.30 works just perfectly with orbit-0.5.7
(good work !) but mayby you also want to tackle down this:

- It doesn't build on top of orbit-mt-0.5.7:
  I'm using the environment variable ORBIT_CONFIG to specify
  the right config-script. This obviously works but there is no
  option to specify that orbit-idl-mt should be used instead
  of orbit-idl.
  However, configure fails to create the makefiles. I get the
  following output when running this command sequence (I have
  both orbit-0.5.7 and orbit-mt-0.5.7 installed in /opt/orbit):

  > export LD_LIBRARY_PATH=/opt/orbit/lib
  > export ORBIT_CONFIG=/opt/orbit/bin/orbit-config-mt
  > configure --prefix=/opt/orbit --with-orbit-prefix=/opt/orbit
              --with-orbit-exec-prefix=/opt/orbit

  [snip]
  checking for orbit-config... /opt/orbit/bin/orbit-config-mt
  checking for ORBit - version >= 0.5.7... yes
  checking for orbit-idl... /usr/bin/orbit-idl
  [snip]
  creating Makefile
  sed: file conftest.s1 line 67: Unterminated `s' command
  sed: file conftest.s2 line 1: Unknown command: ``-''
  [snip]


- The support for predefined CORBA-sequences is broken:

  Try to compile the output 'orbit-idl -lc++' produces
  from the following idl-code:

  module CorbaSigC
  {
    typedef sequence<any> ParamList;

    interface Slot {
      any call( in ParamList params );
    };
  }

  It will contain the following expressions that produce errors:

  -- ::_orbitcpp::c::CORBA_sequence_CORBA_any

     This is declared in orb/corba_sequences.h and so not included
     inside namespace _orbitcpp { namespace c { [...] } }

  -- ::_orbitcpp::c::CORBA_sequence_CORBA_any__alloc

     This isn't declared anywhere !

  I'm sorry that I can't write a buxfix for this myself but I have
  no idea how the correct output would look like and where to handle
  the spcecial sequence types.


Keep going,

  Martin.

[orbitcpp-list] Re: list all servants

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

SGkgQ2xhdWRlLA0KDQpDbGF1ZGUgTGFteSB3cml0ZXM6DQogPiBIaSwNDQogPiANDQogPiBJ
IGFtIHByZXR0eSBuZXcgd2l0aCBDT1JCQSBhbmQgT1JCaXQsIEkgaGF2ZSBkb3dubG9hZGVk
IHRoZQ0NCiA+IGxhdGVzdCB2ZXJzaW9uIG9mIE9yYml0ICgwLjUuNykgYW5kIG9mIE9yYml0
QysrICgwLjMwKS4NDQogPiANDQogPiBJIGhhdmUgbWFkZSBhIHNlcnZhbnQgdGhhdCBiaW5k
cyB0byB0aGUgTmFtZVNlcnZlciB3aXRoIG5vDQ0KID4gcHJvYmxlbS4gIEl0J3MgY2xpZW50
IGlzIGFibGUgdG8gY29ubmVjdCB0byBpdCB3aXRoIG5vDQ0KID4gcHJvYmxlbS4gIEJ1dCwg
dGhlcmUgYXJlIHR3byB0aGluZ3MgdGhhdCBidWdzIG1lLiAgRmlyc3QgSQ0NCiA+IGFtIGFi
bGUgdG8gYmluZCB0aGUgc2VydmVyIHRvIHRoZSBuYW1lIHNlcnZlciBvbmx5IGlmIHRoZXJl
DQ0KID4gaXMgb25seSBvbmUgbGV2ZWwgaW4gdGhlIG5hbWluZyBjb250ZXh0Lg0KDQpZZXAg
LSBJIGNhbiByZXByb2R1Y2UgdGhpcyBwcm9ibGVtIC0gSSdsbCBsb29rIGludG8gaXQuDQoN
CiA+ICBTZWNvbmQsIHRoZQ0NCiA+IGFwcGxpY2F0aW9uIEkgYW0gd3JpdGluZyBjYW4gaGF2
ZSBtdWx0aXBsZSBzZXJ2YW50cyBmb3IgYQ0NCiA+IGdpdmVuIGNhbGwuICBJIGFtIHRyeWlu
ZyB0byAiYnJvd3NlIiBpbiBjKysgdGhlIG5hbWluZw0NCiA+IGNvbnRleHQgdXNpbmcgdGhl
IENvc05hbWluZyBsaXN0IGZ1Y3Rpb24sIGJ1dCB0aGVyZSBJIGFtIG5vdA0NCiA+IGV2ZW50
IGFibGUgdG8gY29tcGlsZS4gIElzIHRoZXJlIGFuIG9yYml0Y3BwIHdvcmtpbmcgZXhhbXBs
ZQ0NCiA+IEkgY2FuIGJhc2UgbXlzZWxmIG9uIHRvIGd1aWRlIG1lLiAgSSBrbm93IHRoYXQg
dGhlcmUgaXMgYSBDDQ0KID4gZXhhbXBsZSB0aGF0IGNvbXBpbGUuICBJIGhhdmUgdHJpZWQg
aXQgYW5kIHdhcyBuZXZlciBhYmxlIHRvDQ0KID4gbGlzdCB0aGUgbmFtaW5nIGNvbnRleHQu
DQ0KDQpJIGhhdmVuJ3QgdHJpZWQgdGhpcy4gSSBzaG91bGQgaGF2ZSBzb21lIHRpbWUgdG8g
Y2hlY2sgdGhpcyB0b21vcnJvdy4NCg0KQ2hlZXJzLA0KDQpQaGlsDQoNClAuUy4gc29ycnkg
YWJvdXQgdGhlIGxhdGUgcmVwbHkgLSBteSBsYXB0b3BzIGJ1c3QgYW5kIEknbSB0eXBpbmcg
b24gYW4NCm9sZCBjb21wYW55IGxhcHRvcC4=

Re: [orbitcpp-list] orbitcpp tests PASSED with gcc3 (pre-release)

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

Hi Richard,

Thanks for doing this. Unfortunately I'm afraid I'm not going to be
able to test/commit this stuff for a few days; My laptop bust 2 weeks
ago (well alright - I dropped it :-(  - it should be back from the
fixers any time now.

Cheers,

Phil


Richard Andrews writes:
 > 
 > I'm pleased to announce that orbitcpp-0.30 builds and passes all tests with
 > gcc3 pre-release 2001-02-18 (with minor changes).
 > 
 > Phil, I've attached the patches I had to make on orbitcpp-0.30.
 > 
 > The changes in orbitcpp_smartptr.hh, I'm not happy with. The
 > const_cast<>()s are a bit of a kludge and I'd like to get rid of them.
 > 
 > The real problem is the code generated to call members. Usually there's a
 > dynamic_cast<Something_var &>() which is passed to a member function. The
 > problem is that this dynamic_cast generates a temporary (r-value) and the
 > compiler (correctly) complains when constructing a Something_out from a
 > non-const r-value generated by the dynamic_cast.
 > 
 > We really need to create a local variable to hold the result of the
 > dynamic_cast in an l-value. That way the constructors in smartptr.hh don't
 > need to take const references and smartptr.hh doesn't need to be changed.
 > 
 > Sorry, but I don't know where to make these changes. Somewhere in
 > pass_skels.cc I suppose.
 > 
 > 
 > The changes to everything/client.cc and server.cc are necessary to make the
 > code standard compliant (trivial changes).
 > 
 > 
 > The mystery segfault problems have disappeared. Probably due to incorrect
 > ORBit library linkage before I got things configured OK.
 > 
 > 
 > Rich

[orbitcpp-list] orbitcpp tests PASSED with gcc3 (pre-release)

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

I'm pleased to announce that orbitcpp-0.30 builds and passes all tests with
gcc3 pre-release 2001-02-18 (with minor changes).

Phil, I've attached the patches I had to make on orbitcpp-0.30.

The changes in orbitcpp_smartptr.hh, I'm not happy with. The
const_cast<>()s are a bit of a kludge and I'd like to get rid of them.

The real problem is the code generated to call members. Usually there's a
dynamic_cast<Something_var &>() which is passed to a member function. The
problem is that this dynamic_cast generates a temporary (r-value) and the
compiler (correctly) complains when constructing a Something_out from a
non-const r-value generated by the dynamic_cast.

We really need to create a local variable to hold the result of the
dynamic_cast in an l-value. That way the constructors in smartptr.hh don't
need to take const references and smartptr.hh doesn't need to be changed.

Sorry, but I don't know where to make these changes. Somewhere in
pass_skels.cc I suppose.


The changes to everything/client.cc and server.cc are necessary to make the
code standard compliant (trivial changes).


The mystery segfault problems have disappeared. Probably due to incorrect
ORBit library linkage before I got things configured OK.


Rich

[orbitcpp-list] smartptr constructors follow-up

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

After doing a little more research on the templated copy constructors in

orbitcpp_smartptr.hh it looks like the CVS gcc compilers are actually
correctly
reporting a problem.

Here's the way things look to me at the moment. Please correct anything
that
I've got screwed up.

Since a non-const reference cannot be bound to an r-value, it isn't
possible to
have an implicit constructor called (as we do, see below) which takes a
non-const reference argument.

This sort of thing is used in the XXX-cpp-skells.cc code generated by
orbitcpp.
A typical example calls a method which takes a non-const
Something_out<T>
reference as a pameter, but a non-const Something_var<T> reference is
passed
(usually the result of a dynamic_cast). Since this results in an r-value
being
passed to the constructor, the compiler rejects it.

Eg.

_self->method( dynamic_cast<Something_var<T> &>(someVariable) );

where method is defined as

class someClass
{
...
returnType method( Something_out<T> & parameter );
}


The dynamic_cast< Something_var<T> & > results in a temporary which is
then passed to the constructor for Something_out<T>. This is only legal
if the
Something_out<T> constructor takes a const reference.

It may be possible to get around this by constructing a local variable
in the
cpp-skell code.

Eg.

Something_var<T> & localVar = dynamic_cast<Something_var<T> &
>(someVariable);

_self->methof(localVar);

Since localVar is not a temporary, the compiler should be happy.

Unfortunately I don't know my way around the code generation stuff
enough to
hack this. Any help would be greatly appreciated.

I'll do some quick hacks on cpp-skell code and check if this actually
solves the
problem. Otherwise the nasty const_cast<> kludge might have to stay in
smartptr.hh.

--

On a related note, libstdc++ is moving to merge with the gcc3 branch in
CVS in
the next couple of days (according to the libstdc++ list) so it looks
like a
gcc3 release will only be a matter of a couple of months away.

--

Rich

[orbitcpp-list] Patch : orbitcpp_smartptr.hh (CVS gcc requirements)

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

Folks,

This gets things to compile properly under CVS
gcc (2001-01-15).

I'd like it if someone could test this and tell me if there are any
problems on other systems. I'm using RH6.2 on i686.

There's a kludge that I don't like that gets around a bug(?) in CVS gcc
which requires templated copy constructors to have a const argument. It's a
const_cast<>() which everyone knows is very nasty...

The diff is against a file from CVS from a couple of days before 0.30, I
think it's the same as 0.30 tho

-- 
Rich

Re: [orbitcpp-list] orbitcpp-0.30 is out!

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

On Mon, Feb 12, 2001 at 12:43:32PM +0000, Phil Dawes wrote:
>  > 1, on sparc-solaris libtool told me, that there are unresolved
>  > references in the idl c++ backend from libstdc++, which it can only
>  > resolv from a shared libstdc++. Which I don't have :( Is is possible to
>  > work around this problem, or should I build a shared libstdc++?
> I'm afraid that the orbit-idl compiler dynamically loads compiler
> backends for other languages, so you do need a shared libstdc++.

FYI, it seems that stlport (www.stlport.org) can be used instead of
libstdc++. Now orbitcpp works nicely on sparc/solaris.

Laszlo

Re: [orbitcpp-list] orbitcpp-0.30 is out!

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

>  > 2, On linux/ia32 (where I have a shared libstdc++) I get tons of
>  > warnings in the generated files using -Wall -W. Most (or all?) of them
>  > is about an unused parameter in the "operator new"s. It would be nice
>  > to see a fix for this in 0.30.1.
> Could you mail me the error please? I only get warnings from the C
> code generated by ORBit on my 32bit intel.

Well, I guess this is the relevant snippet from pass_xlate.cc:

   if(idlStruct.isVariableLength()) {
           m_header
           << endl
           << indent++ << "void* operator new(size_t size) {" << endl
           << indent << "return "
           << IDL_IMPL_C_NS "::"
           << idlStruct.getQualifiedCIdentifier() << "__alloc();" << endl;
           m_header
           << --indent << "};" << endl << endl;
           m_header
           << indent++ << "void operator delete(void* c_struct) {" << endl
           << indent <<  "::CORBA_free(c_struct);" << endl;
           m_header
           << --indent << "};" << endl << endl;

   }

In the generated "void* operator new(size_t size)" the "size" parameter
is not used, that's why I see warnings in the emitted code. Btw, for
clarity reasons I think op. new and delete could be explicitely defined
as "static". But this is just a syntactic sugar.

>  > 3, I'm not sure whether '#pragma inhibit push/pop' is supported, but it
>  > does not seems to work for me. I'm not sure whether it should work in
>  > the C binding either. Is it supported?
> Not yet, but you mentioning it has pushed it to the top of my TODO
> list :-)

Cool :) In the mean time I simply inserted some "#include"s into the
generated headers, and now I can compile my application. Wow!

Laszlo