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