Re: [orbitcpp-list] OrbitCPP FAQ

[Andreas K. <ak...@ix...>]

Hi Bruce & all,

I've thrown together some improved version of the FAQ (already committed
to CVS)

8<-------------------------------------------------------
Thrown together by Andreas Kloeckner <ak...@ix...>.
With contributions from Bruce Ide <nr...@us...>.

-------------------------------------------------------------------------------
Q. What versions of everything?
-------------------------------------------------------------------------------

gcc: 2.95.2, at least. Anything below that version busts you with some 
message over not understanding some template in conjunction with an
overloaded "operator new". If you don't have

ORBit: 0.5.1, with our patches, see patches/ directory, or get a patched
up
copy from ftp://orbitcpp.sourceforge.net/pub/orbitcpp. For CVS
ORBit-C++,
CVS ORBit-C should always be okay. 
However, ORBit 0.5.1-patched isn't good enough for CVS currently.

-------------------------------------------------------------------------------
Q. Why is it important that I install ORBit-C++ to the _exact_ same
place
   as ORBit(-C)?
-------------------------------------------------------------------------------

A: Because the IDL compiler is a shared library backend for orbit-idl,
and it won't be found unless it is in its standard location. Of course,
you may install to some different place, but then you should either

a) symlink <orbit-prefix>/lib/orbit-idl to your custom prefix
or
b) use the --backenddir option of orbit-idl.

-------------------------------------------------------------------------------
Q. How do I compile my first ORBit-C++ app?
-------------------------------------------------------------------------------

Write an IDL file, say "hiworld.idl". [IDL: http://www.omg.org]
Run those four commands in order:

To generate and compile the C portion:

> orbit-idl -lc hiworld.idl
> gcc -c hiworld*.c `orbit-config --cflags server client`

To generate and compile the C++ portion:

> orbit-idl -lc++ hiworld.idl
> c++ -c hiworld.cc `orbit-config --cflags server client`

Then you may proceed to write your client and server interface code and
compile
and link your application.

That's how to compile. How to actually create working objects is
slightly more difficult (But only slightly.) Essentially the IDL
creates a base class from which you derive an implementation which
actually does the work. I've not done much of this myself yet, so
now's the time to go look at those examples again.

If this is all too fast, there's example code up at 
ftp://orbitcpp.sourceforge.net/pub/orbitcpp.

-------------------------------------------------------------------------------
Q. I tried to use some STL in a private variable and the compile
   didn't work...
-------------------------------------------------------------------------------

I think it's a GCC thing, not an OrbitCPP
thing. It may be I didn't install GCC correctly, it may be there's a
bug, it may be I'm doing something stupid. I need to investigate this
some more. (Bruce Ide, nr...@us...)

-------------------------------------------------------------------------------
Q. Why is ORBit-C++ only a wrapper around ORBit-C, anyway?
-------------------------------------------------------------------------------

Three reasons:

a) speed
b) compatibility
c) developer laziness

It is much more hassle to create a mapping from scratch than base it
upon
a ready-made mapping, especially in the case of C and C++. The C code
comes
out well-optimized and nicely debugged. Why should we write a new
compiler
from scratch if all wrapping operations (except exception packing,
granted)
have O(1) complexity?

(by O(1) I mean "no data copying")

-------------------------------------------------------------------------------
Q. What about threads?
-------------------------------------------------------------------------------

ORBit is not currently thread-safe, but there is a patch. (Turn to the
ORBit
folks for this) ORBit-C++ doesn't use unsafe constructions except one
memory info block hack that will hopefully go away.

-------------------------------------------------------------------------------
Q. Which version of ORBit to use with this package?
-------------------------------------------------------------------------------

A: Generally, we try to keep ORBit-C++ working with CVS ORBit, whereas 
publicly released ORBit currently breaks with CVS ORBit-C++. Which is
tough luck for you if you run the Gnome desktop, because it likes 
to be run with ORBit-0.5.1. 
(it doesn't care whether our patches have been applied, however)

My suggestion is: Keep a "Gnome" copy of ORBit (I keep mine in
"/opt/gnome")
and a "development" copy separately (I keep mine in "/opt/orbit"). 
Be sure to only insert the development copy into the path if you want 
to hack ORBit-C++, in order to not mix those installations, which will
be causing nothing but havoc.

-------------------------------------------------------------------------------
Q. I include some standard c or glib header file, and its contents just
seems 
   to disappear.
-------------------------------------------------------------------------------

[This question doesn't apply to the CVS version any more.]

This one is hairy. ORBit-C++ hides away the C implementation of ORBit in
the _orbitcpp::c namespace. Of course, ORBit cannot go without some
standard
header files, which of course carry the obligatory

#ifndef MY_GREAT_HEADER
#define MY_GREAT_HEADER

...

#endif

protection. These MY_GREAT_HEADER macros are not scoped, so once they
are
included inside ORBit-C++'s namespace hierarchy, you won't get at their
contents by including them again. Suggested solution is to include
these files way before anything of the ORBit-C++ stuff, which puts
them into global scope, making them available in _orbitcpp::c and to
your program as well.

-------------------------------------------------------------------------------
Q. I get spurious segfaults in exception handling when linking with 
   liborbitcpp.
-------------------------------------------------------------------------------

This one is also hairy, and I do not have a full understanding of why or
what or where it comes from. However, I know a workaround.

[snip] -------------------------------------------------
--- ltmain.sh.old	Tue Apr 11 02:36:10 2000
+++ ltmain.sh	Tue Apr 11 02:36:22 2000
@@ -1797,7 +1797,7 @@
 	  ;;
 	*)
 	  # Add libc to deplibs on all other systems.
-	  deplibs="$deplibs -lc"
+	  # deplibs="$deplibs -lc"
 	  ;;
 	esac
       fi
[snip] -------------------------------------------------

Locate your copy of ltmain.sh, and apply this patch to it, then run

make maintainer-clean && autogen.sh

WARNING. Watch out. If you apply this patch, you may harm your libtool 
installation. If you do so, you are definitely on your own. Your libtool 
may not work as before, since, as I said, I've just found out 
how to eliminate the segfaults, I don't know exactly what I'm doing.

BTW: compiling a new glibc (2.1.3) also fixed the problem for me. 

-------------------------------------------------------------------------------
Q. What about all those warnings during the build process?
-------------------------------------------------------------------------------

They're harmless. Ignore them.

8<-------------------------------------------------------

Comments?

bye
andy

-- 
Don't innovate, intimidate.