This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: port of omniorb
- To: <K dot Fleischer at Omnium dot de>,<cygwin at cygwin dot com>
- Subject: RE: port of omniorb
- From: "Robert Collins" <robert dot collins at itdomain dot com dot au>
- Date: Tue, 3 Apr 2001 10:54:09 +1000
- Thread-Index: AcC71fxH6WFQEYBOTEKn1bfY/h/B1wAAlEKA
- Thread-Topic: port of omniorb
> -----Original Message-----
> From: Karsten Fleischer [mailto:Karsten.Fleischer@gmx.de]
> Sent: Tuesday, April 03, 2001 10:41 AM
> To: cygwin@cygwin.com
> Subject: Re: port of omniorb
>
>
> > X - done, bug reports accepted
> > C - can't be done, or very hard to do. Should be critical
> regardless -
> > consider patching the source to not need this.
> > O - coded, but possibly not available in cygwin snapshots.
>
> Robert,
> I will have a closer look at the OmniORB sources. Could be
> that some calls
> are #ifdef'ed and not needed for Cygwin.
> If OmniORB could be compiled with the existing Cygwin
> pthreads I'd try to
> compile our application on Cygwin, which would be a good
> regression test for
> the whole Cygwin package (11000 source files, C, C++,
> FORTRAN, CORBA, X11,
> Xm etc.)
>
> Karsten
>
Thank you.
More importantly, if you could see what calls are actually _required_
and what calls are _preferred_.
I.E. the setpri0 calls are almost certainly not _needed_ as they related
to priority, not to data storage. useing these calls as an example, they
may not be #ifdef'ed today, but if you #ifdef them omniORB should still
work.
If you can do this it will let me focus on whats required.
Rob
--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple