Re: [GnomeMeeting-list] Finally! Working gnomemeeting and Gatekeeper!

[Chris Rankin <rankincj yahoo com>]

 --- Craig Southeren <craigs postincrement com> wrote:
> Yes, this flag will prevent any code that
> contains dynamic casts from being linked, which is
> not a problem as none of the code for GM, PWlib or
> OpenH323 contains dynamic casts.

No, you mean it's not a problem for GM. My point is
that GM isn't the exclusive user of Pwlib or OpenH323.

> > Quite
> > possibly gnomemeeting doesn't use dynamic_cast<>
> > directly, but the pwlib/src/ptlib/unix/beaudio.cxx
> > file does and so does the GNU Gatekeeper. 
> 
> The GNU gatekeeper will never be linked with GM, so
> this is not relevant.
> The BeOS audio driver needs to be rewritten to use
> the new plugin audio
> driver system so this is irelevant as well.
> 
> > The absence
> > of any RTTI is why my new Gatekeeper immediately
> > core-dumped whenever I tried to start it.
> 
> See above

Hmm, my understanding is that the -fno-rtti flag is
part of Pwlib configuration, and so is inherited by
*everything* that uses Pwlib. GM is one Pwlib user,
and the GNU Gatekeeper is another. Now the GNU
Gatekeeper uses dynamic_cast<> quite extensively, and
so *does* need RTTI available. This means that it
cannot use any shared objects which have been compiled
without it. So while (obviously) the Gatekeeper will
never be linked with GM, these two Pwlib applications
cannot use the same Pwlib shared libraries. This is
contrary to the intention of having shared libraries.

Please don't tell me that it doesn't make sense to run
the GNU Gatekeeper on the same machine as GM unless
you can guarantee that these are the *only* two
pwlib-based applications in existence, making this the
only situation where this problem could arise.

> If anyone is using dynamic casts (rather than the
> portable PWLib constructs that acheive the same
> result) ...

Umm, isn't dynamic_cast<> part of the ANSI C++
standard? Sounds pretty portable to me. Why reinvent
the wheel?

> It also reduces the size of executable by about 5%,
> so there are benefits.

But you've also increased code-size by writing a
replacement for RTTI. Besides, I can achieve far
greater savings than 5% if my code doesn't have to
work at the end of the day ;-).

My take on this is that if GM wants to use -fno-rtti
then that's fine. But by placing this flag in the
build options for Pwlib then you have forced it upon
all Pwlib applications. This *has* broken the GNU
Gatekeeper at the very least, and possibly other
Pwlib-based applications too. I think it makes more
sense for Pwlib and OpenH323 to leave the RTTI
available for applications that do want to use it.

Cheers,
Chris



	
	
		
___________________________________________________________
Yahoo! Messenger - Communicate instantly..."Ping" 
your friends today! Download Messenger Now 
http://uk.messenger.yahoo.com/download/index.html