[omniORB] More on omniORB4 on Mac OSX

[William Noon]

Following Duncan's suggestion of an overzealous link optimizer, I added
an OMNI_EXPORT_LINK_FORCE_SYMBOL(poa); to poa.cc and OMNI_FORCE_LINK(poa);
to (for want of a better place) corbaOrb.cc.

This kicked the dyld into running the static inits in poa.cc so that the
poaHoldRequestTimeout option doesn't cause the orbOptions to bomb.  Thre
are probably other init that are not running but this and the fixes below
got the c++ echo examples running.

Moving on to the python code, I got next to nowhere running with python
v2.2.  If python is compiled with cycle-gc, it fails to load CORBA.py
with a gc error (didn't save the exact message).  Recompiling without
cycle-gc will allow the CORBA and _omnipy modules to load but it looks
like none of the static initializers are running.  Note that omniOrb3.0.4
is running fine with python v2.2 with cycle-gc on this same machine.

Python 2.2+ (#8, Jan 30 2002, 18:38:35) 
[GCC 2.95.2 19991024 (release)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> from omniORB import CORBA
>>> orb = CORBA.ORB_init(['',],CORBA.ORB_ID)
omniORB: ORB_init failed: unknown option (traceLevel) in configuration file
Traceback (most recent call last):
  File "<stdin>", line 1, in ?
  File "/usr/local/sources/omni2a/lib/python/CORBA.py", line 499, in ORB_init
    sys.modules["CORBA"] = omniORB.CORBA
  File "/usr/local/sources/omni2a/lib/python/CORBA.py", line 509, in __init__
    sys.modules["CORBA"] = omniORB.CORBA
omniORB.CORBA.INITIALIZE: Minor: INITIALIZE_InvalidORBInitArgs, COMPLETED_NO.
>>> 
*** malloc[24368]: Deallocation of a pointer not malloced: 0x259e70; This could be a double free(), or free() called with the middle of an allocated block; Try setting environment variable MallocHelp to see tools to help debug

The malloc error is probably due to a dtor assuming that some pointer must
have been init'd.

All the code works on linux (gcc 2.96) and python v2.2 (with cycle-gc).
Any further suggestions would be appreciated.

Here is a patch to the net interface discovery code to handle variable length
ifreq structures.  It is pretty much right out of Stevens:

RCS file: /cvsroot/omni/src/lib/omniORB/orbcore/tcp/Attic/tcpTransportImpl.cc,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 tcpTransportImpl.cc
220a221
>   char *ptr, *buf;
232c233
<     char* buf = (char*) malloc(len);
---
>     buf = (char*) malloc(len);
254,259c255,259
<   int total = ifc.ifc_len / sizeof(struct ifreq);
<   struct ifreq* ifr = ifc.ifc_req;
<   for (int i = 0; i < total; i++) {
< 
<     if ( ifr[i].ifr_addr.sa_family == AF_INET ) {
<       struct sockaddr_in* iaddr = (struct sockaddr_in*)&ifr[i].ifr_addr;
---
>   struct ifreq* ifr;
>   for (ptr = buf; ptr < buf + ifc.ifc_len; ) {
>     ifr = (struct ifreq *)ptr;
>     if ( ifr->ifr_addr.sa_family == AF_INET ) {
>       struct sockaddr_in* iaddr = (struct sockaddr_in*)&ifr->ifr_addr;
263a264,266
>     ptr += (ifr->ifr_addr.sa_len > sizeof(struct sockaddr) ? 
>             (sizeof(struct ifreq) - sizeof(struct sockaddr) +
>             ifr->ifr_addr.sa_len) : sizeof(struct ifreq));
265c268
<   free(ifc.ifc_buf);
---
>   free(buf);



And here is a cast needed by the ssl code:

RCS file: /cvsroot/omni/src/lib/omniORB/orbcore/ssl/Attic/sslContext.cc,v
retrieving revision 1.1.2.7
diff -r1.1.2.7 sslContext.cc
341c341
<   unsigned long id = pthread_self();
---
>   unsigned long id = (unsigned long)pthread_self();


--Bill Noon
Northeast Regional Climate Center
Cornell University