orbitcpp-list

[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

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

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 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:
> 
> 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 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