[omniORB] problems on cygwin compilation

[Duncan Grisby]

On Friday 30 March, Bruno PATIN wrote:

> I try to compile omniorb on cygwin platform. I load Python 2.1b.1 and
> configure it with the option --with-thread=no.

It doesn't matter for omniidl, but why are you compiling Python
without thread support?  If it's because you can't use threads with
cygwin, there's no hope of compiling omniORB.

>    I succeed int the
> creation of omkdepend and i am stopped in the compilation of omniidl.
> Imust first say that I saw what I think is an error in the source
> idlutil.cc at line 171 as the procedure called in my version was
> strtoull and not strtoul. Even with this modification, I arrive at what
> you see on the file joined that is the result of the make command at the
> omniidl directory.
> 
> I choose the platform i586_linux_2.0_glibc2.1 as it corresponds (so I
> think) to the version of my libraries.

I would be very surprised if you managed to get very far using the
Linux platform file with cygwin. I don't know how Unix-like cygwin
makes Windows appear, but I doubt it goes anything like far enough.
The particular problem you are having with omniidl is that the linker
doesn't realise that the symbols it can't find live within the Python
executable. It's trying to build a Unix-style .so dynamic library.
Does cygwin go that far in its Unix emulation?  I imagine you have to
figure out how to create a Windows DLL.

Things will get much worse when you try to compile the ORB core
libraries. There are enormous numbers of system dependencies there.
It's not going to be a small task.

I think you would have better luck starting from the x86_nt_4.0
platform file, and modifying it to use the cygwin compiler.

Cheers,

Duncan.

-- 
 -- Duncan Grisby  \  Research Engineer  --
  -- AT&T Laboratories Cambridge          --
   -- http://www.uk.research.att.com/~dpg1 --