orbitcpp-list

[orbitcpp-list] ORBit-0.5.3

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

Doh! Those following the ORBit list will have noticed that Elliot's just
released ORBit-0.5.3. 

Here we go again! ;-)

Cheers,

Phil.

Re: [orbitcpp-list] Understanding orbit-c++

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

Adam Young wrote:
> 

[snip...]

> 3) autogen, make and install glib into development directory (I chose
> /usr/local/devel/  side question does a trailing slash have any effect
> on autogen/ configure)

I don't think so. 


[snip...]

> 6)and finally for orbitcpp
> 
> cd ../orbitcpp
> ./autogen.sh -prefix /usr/local/devel/
> make
> 
> This is the step thaht fails for me.  I get a build error in
> orbitcpp_tools looking MemHow.  I know this is in
> PREFIX/include/orb/allocators.h
> 
> But I don't see a -I/usr/local/devel/include in the compile command.
> 

Could you mail the compile command? - cheers.


> Note that I also tried it with
> --with-orbit-prefix=/usr/local/devel
> 
> Possily related question:
> 
> IN the configure output I found this snippet:
> *** Your copy of orbit-idl doesn't support --backenddir
> *** This means that you will have to install the C++ idl compiler
> back-end
> *** (with 'make install') before you can build the tests.
> 
> Is this indicitave of it not finding the right ORBit code?
> 

Yes! The CVS head version of ORBit definitely has --with-orbit-prefix.

Hmmm... 
<gets off his arse and attempts to build ORBit/orbitcpp from scratch>

I may have the answer: 
I've just attempted to do this on a fresh redhat 6.2 system with helix
gnome, and helix gnome comes with ORBit-0.5.2. The problem is that the
ORBit in CVS head is fixed at 0.5.1 for some god-only-knows reason. This
means that the configure script gets confused (and prints out a verbose
warning msg), but ultimately doesn't stick the correct include and lib
directives into the makefiles.

I fixed this by editing the ORBIT_MICRO_VERSION variable in ORBit
configure.in from 1 to 2, which fixed the problem.

Does this help?

> THanks to all of you for your patience.
> 

You're welcome; - thanks for your perserverance!

Cheers,

Phil.

Re: [orbitcpp-list] Understanding orbit-c++

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

Andreas Kloeckner wrote:
> 
> On Tue, Jul 25, 2000 at 08:22:58PM -0500, Dave Smith wrote:
> >
> > Greetings again...
> >
> > Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
> > and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
> > some reason. At any rate, most of the stuff appears to work.
> 
> Yup, everything-typedef fails for some reason for me, too. I'll look into
> this when the next exams are over (Aug 3).
> 


Err.. yeah, the everything-typedef test is broken at the moment.
Basically this is a test which uses all the 'everything' test
implementation files, but uses an IDL file where each item is typdefed.
Unfortunately it doesn't all work at the moment.

Sorry folks,

Phil.

Re: [orbitcpp-list] Getting setup

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

Dave Smith wrote:
> 
> On Mon, Jul 24, 2000 at 06:44:08PM +0200, Andreas Kloeckner wrote:
> > I've browsed gnome idl files briefly, and imho, it should suffice. I
> > don't really remember what our last release was up to in terms of features.
> > You can try, but I doubt it will work. The bad news is that CVS ORBit-C++
> > breaks with stock (or patched) ORBit-0.5.1. (It works with CVS ORBit, however,
> > which in turn breaks Gnome)
> 
> So I need to use ORBit HEAD? I can't seem to get that to build :( Checking
> it out and running autogen.sh I get a message telling me I need to use
> 
> -r orbit-stable-0-5 (which I believe to be ORBit 0.5.2, correct?)?! :)
> 
> D.
> 

This goes away if you set the CERTIFIED_GNOMIE env variable to
something. Checkout the configure.in for details,

Cheers,

Phil.

Re: [orbitcpp-list] Getting setup

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

Andreas Kloeckner wrote:
> 
> Hi Dave,
> 
> On Sun, Jul 23, 2000 at 05:02:42PM -0500, Dave Smith wrote:
> > I'd starting to work on some C++ components for use in GNOME, and i'm wondering how far along
> > orbit-cpp is in terms of functionality.
> 
> Current CVS features everything except:
> * attributes

Actually this is implemented.

Cheers,

Phil.

Re: [orbitcpp-list] Understanding orbit-c++

[Adam Y. <ay...@fo...>]

Well, I'm still stuck in the config stage, although I am learning a
hellofalot about how CVS, autogen, and gnome development are organized.  

So to try to summarize:

pre) in ~/.bashrc

export CERTIFIED_GNOMIE="Getting There"


1) Log in to Gnome CVS.
2) checkout (or update) glib and ORbit
3) autogen, make and install glib into development directory (I chose
/usr/local/devel/  side question does a trailing slash have any effect
on autogen/ configure)
cd glib
./autogen.sh -prefix /usr/local/devel/
make
make install

4)autogen, make and install ORBit into development directory  

cd ../ORBit
./autogen.sh -prefix /usr/local/devel/
make
make install

5)Get orbitt cpp from CVS

6)and finally for orbitcpp

cd ../orbitcpp
./autogen.sh -prefix /usr/local/devel/
make

This is the step thaht fails for me.  I get a build error in
orbitcpp_tools looking MemHow.  I know this is in 
PREFIX/include/orb/allocators.h

But I don't see a -I/usr/local/devel/include in the compile command.

Note that I also tried it with 
--with-orbit-prefix=/usr/local/devel


Possily related question:

IN the configure output I found this snippet:
*** Your copy of orbit-idl doesn't support --backenddir
*** This means that you will have to install the C++ idl compiler
back-end
*** (with 'make install') before you can build the tests.

Is this indicitave of it not finding the right ORBit code?

THanks to all of you for your patience.

Adam


> Important: Did you also install glib into your safe directory (would be
> good), and does ORBit-C++ use -I/your/gnome/directory when compiling
> (would be bad)?

Re: [orbitcpp-list] Understanding orbit-c++

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

On Tue, Jul 25, 2000 at 08:22:58PM -0500, Dave Smith wrote:
> 
> Greetings again...
> 
> Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
> and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
> some reason. At any rate, most of the stuff appears to work.

Yup, everything-typedef fails for some reason for me, too. I'll look into
this when the next exams are over (Aug 3). 

Important: Did you also install glib into your safe directory (would be 
good), and does ORBit-C++ use -I/your/gnome/directory when compiling 
(would be bad)?

> 
> Now I'm starting to wonder how this binding/wrapper works...are there any documents explaining your approach
> and/or theories?

see the HACKING file.

> I'm a C++ person and would prefer to _not_ try and write bonobo components in C (unlike certain other parties
> on GNOME) :) My next question is this: what are the dependencies of ORBit and how hard will it be to setup
> once bonobo starts getting widespread use? I want to make my code as easy as possible to build, if people
> wish to do so.

ORBit only depends on glib. ORBit-C++ does not add any dependency.
A working STL is only necessary for building the IDL compiler.
ORBit-C++ should not, in its final state, be any harder to set up
than ORBit itself.

> why do I have to run the compiler twice?

because by doing 

orbit-idl -lc++ blah.idl

you generate classes that wrap the stuff you generate by doing

orbit-idl -lc blah.idl.

bye
andy

-- 
Don't innovate, intimidate.

[orbitcpp-list] Understanding orbitcpp

[Dave S. <da...@ja...>]

One more question...why do i have to run the IDL compiler twice? (According to the README in /)

D.

[orbitcpp-list] Understanding orbit-c++

[Dave S. <da...@ja...>]

Greetings again...

Well, I managed to get CVS ORBit & CVS ORBit-cpp working in a "safe" directory. IDL compiler seems to work
and everything is happy. I can run the tests, tho the tests/everything-typedef doesn't want to build for
some reason. At any rate, most of the stuff appears to work.

Now I'm starting to wonder how this binding/wrapper works...are there any documents explaining your approach
and/or theories?

I'm a C++ person and would prefer to _not_ try and write bonobo components in C (unlike certain other parties
on GNOME) :) My next question is this: what are the dependencies of ORBit and how hard will it be to setup
once bonobo starts getting widespread use? I want to make my code as easy as possible to build, if people
wish to do so.

I guess that's all the questions I can think of for now. :) 

D.

Re: [orbitcpp-list] Getting setup

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

On Tue, Jul 25, 2000 at 02:39:27PM -0500, Dave Smith wrote:
> On Mon, Jul 24, 2000 at 06:44:08PM +0200, Andreas Kloeckner wrote:
> > I've browsed gnome idl files briefly, and imho, it should suffice. I 
> > don't really remember what our last release was up to in terms of features.
> > You can try, but I doubt it will work. The bad news is that CVS ORBit-C++
> > breaks with stock (or patched) ORBit-0.5.1. (It works with CVS ORBit, however,
> > which in turn breaks Gnome)
> 
> So I need to use ORBit HEAD? I can't seem to get that to build :( Checking
> it out and running autogen.sh I get a message telling me I need to use
> 
> -r orbit-stable-0-5 (which I believe to be ORBit 0.5.2, correct?)?! :)

Right. Fix it by doing 

export CERTIFIED_GNOMIE="yes,ma'am"

in your .profile. (You may however substitute "yes,ma'am" by any subjective
rating of your abilities. :-)

bye
andy
-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] Getting setup

[Dave S. <da...@ja...>]

On Mon, Jul 24, 2000 at 06:44:08PM +0200, Andreas Kloeckner wrote:
> I've browsed gnome idl files briefly, and imho, it should suffice. I 
> don't really remember what our last release was up to in terms of features.
> You can try, but I doubt it will work. The bad news is that CVS ORBit-C++
> breaks with stock (or patched) ORBit-0.5.1. (It works with CVS ORBit, however,
> which in turn breaks Gnome)

So I need to use ORBit HEAD? I can't seem to get that to build :( Checking
it out and running autogen.sh I get a message telling me I need to use

-r orbit-stable-0-5 (which I believe to be ORBit 0.5.2, correct?)?! :)

D.

[orbitcpp-list] ORBit CVS and more ...

[Michael R. <mi...@ru...>]

Hi !

The CVS is for ORBit is hosted on the GNOME site.
Have look at http://rumpfonline.de/orbit/faq.html#orbit on how to access
CVS. 
See http://rumpfonline.de/orbit for general ORBit related info.
BTW, for ORBit C++ there is a pointer in the language mapping section.

Michael

Re: [orbitcpp-list] Getting setup

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

Hi Dave,

On Sun, Jul 23, 2000 at 05:02:42PM -0500, Dave Smith wrote:
> I'd starting to work on some C++ components for use in GNOME, and i'm wondering how far along
> orbit-cpp is in terms of functionality. 

Current CVS features everything except:
* attributes
* arrays
* unions
* the dynamic stuff and typecodes
* non-explicit instantiation

I've browsed gnome idl files briefly, and imho, it should suffice. I 
don't really remember what our last release was up to in terms of features.
You can try, but I doubt it will work. The bad news is that CVS ORBit-C++
breaks with stock (or patched) ORBit-0.5.1. (It works with CVS ORBit, however,
which in turn breaks Gnome)

> I currently have orbit 0.5.2 on my machine (debian - woody)
> ..do i need to use the patched 0.5.1 instead for orbit-cpp to work properly?

You might
a) patch up a copy of 0.5.2 yourself, using the stuff from the patches 
   directory. Just apply 2000-04-13.orbit-patch. [It fixes one crucial
   sequences bug]
   2000-03-* is only necessary if you don't want to install ORBit-C++
   into the ORBit tree.
   2000-04-14 has been fixed in another way.
   [Expect to be tampering a bit with ORBit-C++]
b) go with CVS ORBit.
   [Expect to be tampering with Gnome]

> also some notes on stability would be good :)

It should be solid enough for production use, and we do not intend major
redesigns. However, it's still development code, and should be treated
appropriately. <plug> We always *love* to hear your bug reports. </plug>

Hope this helps
Andy

-- 
Don't innovate, intimidate.

Re: [orbitcpp-list] Postmortem

[<bir...@co...>]

On 23 Jul 00, at 11:52, Andreas Kloeckner wrote:

> On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> > Don't try it with GCC 2.96
> > 
> > Adam
> > 
> > _______________________________________________
> > orbitcpp-list mailing list
> > orb...@li...
> > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> > 
> 
> I've checked the gcc homepage yesterday, they didn't say anything about
> 2.96 being out, nor did their ftp site carry it. :?
> 
> andy
> 
> PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
> for another project"?
> 
> -- 
> Don't innovate, intimidate.
> 

The weekly release carry the 2.96 in its version documentation. Try the newest 
beta, do a gcc -v and you'll see it ;)



-------------------------------------------
Horst 'hellicop' Birthelmer
bir...@co...  
hel...@us...

http://www.birthelmer.de
http://www.hellicop.net
-------------------------------------------

[orbitcpp-list] Config Questions

[Adam Y. <ay...@fo...>]

Where is the CVS for ORBit?  I was only able to find the latest tar.gz. 
The AnonCVS link of the rhad site is dead.


In order to synch up the Orbit and orbitcpp trees, In my orbit directory 
./configure -prefix=/usr/local/devel
make, make check and install

then in  orbittcpp
./configure -prefix=/usr/local/devel
make, make check and install

Am I on the right track.  I got some build errors, but they could be
from an out of date ORBit build.

c++ -DHAVE_CONFIG_H -I. -I. -I. -I.. -I.. -I/usr/local/lib/glib/include
-I/usr/local/include -I/usr/include -g -O0 -Wall
-Wp,-MD,.deps/orbitcpp_tools.pp -c orbitcpp_tools.cc  -fPIC -DPIC -o
.libs/orbitcpp_tools.lo
orbitcpp_tools.cc: In function `void _orbitcpp::save_meminfo(void *)':
orbitcpp_tools.cc:77: `ORBit_MemHow' undeclared (first use this
function)
orbitcpp_tools.cc:77: (Each undeclared identifier is reported only once
orbitcpp_tools.cc:77: for each function it appears in.)
orbitcpp_tools.cc:77: parse error before `='
orbitcpp_tools.cc:78: `how' undeclared (first use this function)
orbitcpp_tools.cc: At top level:
orbitcpp_tools.cc:101: syntax error before `['
orbitcpp_tools.cc: In function `void
_orbitcpp::point_to_memhow_none(void **)':
orbitcpp_tools.cc:105: `orbit_memhow_none' undeclared (first use this
function)
make[1]: *** [orbitcpp_tools.lo] Error 1
make[1]: Leaving directory `/home/ayoung/devel/orbitcpp/orb'
make: *** [all-recursive] Error 1

Re: [orbitcpp-list] Postmortem

[Adam Y. <ay...@fo...>]

No no, I'm still; around.  Just the postmortem on the issue I filled
everyone's inbox with.. 2.96 was required for Mico development.  I didn
;t realize I still had a non supported gcc.  I've reformed my ways...for
now.

Adam





Andreas Kloeckner wrote:
> 
> On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> > Don't try it with GCC 2.96
> >
> > Adam
> >
> > _______________________________________________
> > orbitcpp-list mailing list
> > orb...@li...
> > http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> >
> 
> I've checked the gcc homepage yesterday, they didn't say anything about
> 2.96 being out, nor did their ftp site carry it. :?
> 
> andy
> 
> PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
> for another project"?
> 
> --
> Don't innovate, intimidate.
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

[orbitcpp-list] Getting setup

[Dave S. <da...@ja...>]

Greetings...

I'd starting to work on some C++ components for use in GNOME, and i'm wondering how far along
orbit-cpp is in terms of functionality. I currently have orbit 0.5.2 on my machine (debian - woody)
..do i need to use the patched 0.5.1 instead for orbit-cpp to work properly?

Also, there doesn't seem to be a status page anywhere -- can someone do a run down of what orbit-cpp
lacks in order to be usable on a day-to-day basis..also some notes on stability would be good :)

Thanks in advance...

D.

Re: [orbitcpp-list] others environments...

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

Hi Felipe,

Err.. what's an OMNI project?

ORBit-C++ is designed to run on unix platforms using gnu
autoconf/automake. It's conceivable that it would compile using windows
compilers like C++Builder or Visual C++ (providing you've already got a
working windows version of ORBit), but I've never tested it.

Cheers,

Phil.


Felipe Bittencourt wrote:
> 
> Hi, I am new in the list...
> Can I use another environment, like C++Buider, to build OMNI projects?
> Or just Visual C++?
> 
> Thanks for help!!
> 
> Felipe
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list

Re: [orbitcpp-list] Postmortem

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

On Fri, Jul 21, 2000 at 06:24:05PM -0700, Adam Young wrote:
> Don't try it with GCC 2.96
> 
> Adam
> 
> _______________________________________________
> orbitcpp-list mailing list
> orb...@li...
> http://lists.sourceforge.net/mailman/listinfo/orbitcpp-list
> 

I've checked the gcc homepage yesterday, they didn't say anything about
2.96 being out, nor did their ftp site carry it. :?

andy

PS: btw, what do you mean by "postmortem"? is that "bye folks, i'm going
for another project"?

-- 
Don't innovate, intimidate.

[orbitcpp-list] Postmortem

[Adam Y. <ay...@fo...>]

Don't try it with GCC 2.96

Adam

Re: [orbitcpp-list] others environments...

[Bruce I. <nr...@us...>]

Felipe Bittencourt wrote:
> 
> Hi, I am new in the list...
> Can I use another environment, like C++Buider, to build OMNI projects?
> Or just Visual C++?
> 
> Thanks for help!!
> 

I wasn't aware that you could even use Visual C++ to build OrbitCPP
projects. Though the IDL compiler DOES put out fairly standard C++
code...

-- 
Bruce Ide                        nr...@us...
If trees screamed would we be as quick to cut them down? Possibly,
if they screamed all the time.

Re: [orbitcpp-list] OrbitCPP FAQ

[Bruce I. <nr...@us...>]

Andreas Kloeckner wrote:
> 
> Hi Bruce & all,
> 
> I've thrown together some improved version of the FAQ (already committed
> to CVS)
> (FAQ Removed for brevity)
> Comments?
> 

Looks good! That should be enough to at least get people started.

-- 
Bruce Ide                        nr...@us...
If trees screamed would we be as quick to cut them down? Possibly,
if they screamed all the time.

[orbitcpp-list] others environments...

[Felipe B. <fel...@vo...>]

Hi, I am new in the list...
Can I use another environment, like C++Buider, to build OMNI projects?
Or just Visual C++?

Thanks for help!!

Felipe

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.

[orbitcpp-list] OrbitCPP FAQ

[Bruce I. <nr...@us...>]

I'm sending this on. It ain't much, but it's a little more than you have
right now. It's currently in plain text. Feel free to do whatever you
want with it.

-- 
Bruce Ide                        nr...@us...
If trees screamed would we be as quick to cut them down? Possibly,
if they screamed all the time.