Re: [GnomeMeeting-list] A handshake problem?

[Chris Worley <cworley symbionsys com>]

On Sat, 2002-01-12 at 11:50, Damien Sandras wrote:
> The problem was easy to fix, but hard to find out ;)
> edit pwlib/src/ptlib/unix/oss.cxx
> find the 116 in the file
> and remove that number of the list ;)
> It will work!

It might work, if I can get this to compile/link ;)

Pwlib seems to compile and link fine.

If I can dynamically link this pwlib into the existing gnomemeeting (the
0.12.2 Mandrake version installed on SuSE 7,3), then I'd could test
this, but I don't quite understand how this gets linked, or even if it's
dynamically linked at all.  "Ldd"'ing gnomemeeting shows a dependence on
"/usr/lib/libpt...", but the pwlib only made
"libpt_linux_x86_r.so.1.2.5", which isn't reported by ldd as a
gnomemeeting dependency.  All I could think was that it wasn't a
dependancy known to ldd (i.e. gnomemetting loads it procedurally as a
"plug in").  I tried replacing "/usr/lib/libpt_linux_x86_r.so.1.1*" with
"pwlib/lib/libpt_linux_x86_r.so.1.2.5", but that did not solve the
problem.

So, I guess this change is statically linked... 

Openh323 starts with a big problem in
"../pwlib/tools/asnparser/obj_linux_x86_r/asnparser"... it segv's before
reaching "main" (which in C++, means it's some class initialization
problem).  But, I noticed
"../pwlib/tools/asnparser/obj_linux_x86_d/asnparser" did not have the
same problem, so I forced openh323 to use it instead.  for a few
thousand lines, whatever asnparser does was complaining of memory
leaks.  But, I let it go on and the rest seem to compile okay.

Gnomemeeting's "configure" was problematic, the incantation wound up
looking like:

./configure  --with-openh323-includes=/home/cworley/openh323/include/
--with-openh323-libs=/home/cworley/openh323/lib/
--with-ptlib-includes=/home/cworley/pwlib/include/ptlib/
--with-openssl-includes=/usr/local/ssl/include/openssl/

But, it still couldn't find the ptlib includes, even though the file it
was looking for was in the directory I referenced; the same was true for
openssl.  I eventually got around both these problems by making
"configure" pass these failures.

Ldap made for a big compile problem (I don't even use ldap):
openh323/include has ldap.h, but some of the other gnomemeeting files
require other ldap headers, which I found in
/opt/gnome/include/mozilla/.  Furthermore, openh323's ldap.h included a
header file from pwlib ("asn...h"), that caused the compiler to barf.  I
manually changed the Makefiles to search for headers in
"/opt/gnome/include/mozilla/", and renamed "openh323/include/ldap.h" to
something the compiler wouldn't recognize, and gnomemeeting compiled.

The resulting gnomemeeting dies while setting up the listener, from gdb:

  Received Real-time signal 0 in LWP 4004 while waiting for SIGSTOP.

  Program received signal SIGSEGV, Segmentation fault.
  [Switching to Thread 4101 (LWP 4067)]
    0x4043d733 in H323ListenerTCP::Accept (this=0x817b2c8,   
    timeout= 0xbf1ffa58)
      at transports.cxx:875
  875       if (socket->Accept(listener)) {
  Current language:  auto; currently c++
  (gdb) where
  #0  0x4043d733 in H323ListenerTCP::Accept (this=0x817b2c8,   
     timeout= 0xbf1ffa58)
        at transports.cxx:875
  #1  0x4043e586 in H323ListenerTCP::Main (this=0x817b2c8) at 
     transports.cxx:1007
  #2  0x40a53ecd in PThread::PX_ThreadStart () from /usr/lib/libpt.so.1

So, it would be best if I could get the pwlib change to link with the
existing gnomemeeting.  Otherwise, can someone tell me what I'm doing
wrong when making gnomemeeting?

Thanks,

Chris