port to NEXTSTEP 3.x

[Sai-Lai Lo]

--0DCm1Kk/6b
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Lars Immisch has done a port of omniORB_2.2.0 to NEXTSTEP 3.x. I have put
the port in ftp://ftp.orl.co.uk/pub/omniORB/omniORB_2.2.0_NS3.3.tar.gz.

I'll merge the changes into the coming 2.4.0.

If you have a x86 box running NEXTSTEP, please try out the port and provide
some feedback to Lars.

Sai Lai

--------------


--0DCm1Kk/6b
Content-Type: message/rfc822
Content-Transfer-Encoding: 7bit

CONTENT-TRANSFER-ENCODING: quoted-printable
MIME-Version: 1.0 (NeXT Mail 3.3 v118.2)
Content-Type: text/plain; charset=us-ascii
content-length: 3168
Return-Path: <lars@googleplex.ibp.de>
Received: from googleplex.ibp.de by mailhost.orl.co.uk (SMI-8.6/HUB-ORL-0.5)
	id SAA09658; Mon, 20 Oct 1997 18:17:26 +0100
Received: (from lars@localhost) by googleplex.ibp.de (8.7.3/8.7.3) id TAA05120 for omniorb@orl.co.uk; Mon, 20 Oct 1997 19:16:41 +0200 (GMT+0200)
Message-Id: <199710201716.TAA05120@googleplex.ibp.de>
X-Nextstep-Mailer: Mail 3.3 (Enhance 2.0b5)
Received: by NeXT.Mailer (1.118.2)
From: Lars Immisch <lars@ibp.de>
To: omniorb@orl.co.uk
Subject: port to NEXTSTEP 3.3
Date: Mon, 20 Oct 97 19:16:37 +0200

Hi,

I did a port of omniORB2 to NEXTSTEP 3.3 Motorola (the capitalization is =
guarantueed to be wrong ;-) with gcc 2.7.2. I would be glad if you would add =
it to the list of ports.

I have no test machine with NEXTSTEP 3.3 Intel so I cannot verify that =
configuration - but all it should require is a new i386_nextstep_3.3.mk with =
the following platform defines:

PLATFORM_CPPFLAGS =3D -DNeXT -D__i386__ -D__OSVERSION__=3D33

The port does not use the posix compatibility layer, so it might work on =
OpenStep 4.x with little to no modifications. I also hope that it should =
serve as a good starting point for Rhapsody.

In which format would you like to receive my changes? As diffs to the =
original distribution?

Notes:

The omnithread port was rather straightforward since mach threads are =
similar to posix threads. The relevant files are mach.h and mach.cc.

There are two differences, though:=20
- the mach conditions do not have a timed wait. I emulate it by starting a =
new thread that wakes up the waiting thread in time if the condition is not =
signalled. This is less than ideal if many threads use timed_wait, but it is =
only used in the examples, so it seemed ok.
- mach cthreads have thread local data, but only one slot. This port assumes =
exclusive ownership of the thread local data, so when users overwrite the =
thread data with cthread_set_data(), they break omnithread (!). I think this =
is acceptable since omnithread users are supposed to implement thread local =
data by subclassing omni_thread, not by other means.

I changed the signal related code in orb.cc to BSD semantics if NeXT is =
#defined. It would be more general to bracket this change with something =
like #ifdef BSD_SIGNALS ... #endif, but it is only a couple of lines in one =
file, so I didn't do it - it would anyway only make sense if you would =
supported this #define.

In omniNames/log.cc, I changed the call to uname to a call to gethostname, =
again only if #NeXT is defined. I think gethostname is supported on more =
platforms than uname, so changing the code to use gethostname in any case =
except WIN32 should be more general (ultra-unimportant).

I have added the #pragma prefix "omg.org" to Naming.idl

I added support for BSD fork/wait  semantics to =
src/tool/omniidl2/driver/drv_fork.cc and =
src/tool/omniidl2/driver/drv_preproc.cc.

CORBA_sysdep.h had to be augmented by byte order defines for __m68k__

There is no support for shared libs.

I have tested all examples.

I had to change the Makefiles in src/lib/omnithread and src/lib/omniORB2 to =
run ranlib after installing the library via cp because of the following bug =
resp. feature of ld (copied from man ranlib):

BUGS
     The way libraries used to be created, errors were possible
     if the library was modified with ar(1) and the table of con-
     tents was not updated by rerunning ranlib(1).  Thus the link
     editor, ld, warns when the modification date of a library is
     more recent than the creation date of its table of contents.
     Unfortunately, this means that you get the warning even if
     you only copy the library.

Cheers,

Lars Immisch
--
lars@ibp.de=

--0DCm1Kk/6b--