RE: port of omniorb

RE: port of omniorb

[Fleischer, Karsten (K.)]

> What's missing in the pthread implementation? Give me a direction or
> particular function list and I'll see what I can do.

A quick grep on the posix.cc source file gives the following functions:

pthread_attr_create
pthread_attr_delete
pthread_attr_destroy
pthread_attr_init
pthread_attr_setdetachstate
pthread_attr_setprio
pthread_attr_setschedparam
pthread_attr_setstacksize
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_create
pthread_delay_np
pthread_detach
pthread_exit
pthread_get_expiration_np
pthread_getspecific
pthread_init
pthread_join
pthread_key_create
pthread_keycreate
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_self
pthread_setprio
pthread_setschedattr
pthread_setschedparam
pthread_setspecific
pthread_yield


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Earnie Boyd]

"Fleischer, Karsten (K.)" wrote:
> 
> > What's missing in the pthread implementation? Give me a direction or
> > particular function list and I'll see what I can do.
> 
> A quick grep on the posix.cc source file gives the following functions:
> 

This isn't what Robert asked.  He asked what is missing for your build. 
Robert is well aware of what is already existing as he is currently
maintaining the PTHREAD routines for Cygwin.  He is trying to get
information about what you need to add it to Cygwin on an as needed
basis.  He doesn't have time to fit all of PTHREAD in the library all at
once.

Earnie.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

I've done some research.

Draft version 10 was adopted with minor variations as the posix
standard. I've been coding off the single unix specification version2,
which is a superset of the posix standards.

So you can assume cygwin is draft version 10, and you won't be far off.

The next cygwin snapshot to be released (Dated after Apr -10) will have
nearly all the functions from that spec. Not all actually _do_ anything
:]. They all return appropriate errors if they aren't supported. The
only missing function is pthread_atfork, and the main missing
functionality is the core of pthread_cancel*. The cancel functions do
work, they just don't do anything. There's around 30 other library
functions that have to be updated to provide full cancellation point
support so that is a long term project.

In short: if you get a snapshot with this code in it, miniORB should
build OOTB. If it doesn't.. please let me know (via the list).

Rob


----- Original Message -----
From: "Karsten Fleischer" <Karsten.Fleischer@gmx.de>
To: <cygwin@cygwin.com>
Sent: Thursday, April 05, 2001 10:07 AM
Subject: RE: port of omniorb


> > sched_yield is in the current snapshots for cygwin. I implemented it
a
> > couple of weeks ago :]
>
> Good. We can then assume draft version 10, which is the highest number
I
> have seen in the OmniORB makefiles. Or was it 11???
>
> Karsten
>
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Karsten Fleischer]

> sched_yield is in the current snapshots for cygwin. I implemented it a
> couple of weeks ago :]

Good. We can then assume draft version 10, which is the highest number I
have seen in the OmniORB makefiles. Or was it 11???

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Robert Collins]

> -----Original Message-----
> From: Karsten Fleischer [ mailto:Karsten.Fleischer@gmx.de ]
> Sent: Thursday, April 05, 2001 9:41 AM
> To: cygwin@cygwin.com
> Subject: Re: port of omniorb
> 
> 
> > > Which pthread draft version do we have on Cygwin?  At least 8, I
> > think...
> > > Robert?
> >
> > The original work - I have no idea.
> 
> Me neither. I was just guessing. Assuming version 8 seems 
> reasonable to me
> (pthread_attr_setdetachstate is/will be implemented in Cygwin and
> pthread_yield is called rather than sched_yield from OmniORB).

sched_yield is in the current snapshots for cygwin. I implemented it a
couple of weeks ago :]
 
> > I'm working of the documentation at www.opengroup.org (searching on
> > google is the easiest way to a good entry point). They don't mention
> > draft versions there.. I'm goping to have to dig up the current IEEE
> > specs I can see.
> 
> Hmm, as I mentioned before I'm not very familiar with 
> pthreads but somehow I
> remember seeing the term "draft" in this context more than once. HP-UX
> headers? Dunno. I'll do a quick search on the HP-UX and SunOS 
> systems at
> work tomorrow.
> 
> > If the project uses autoconf...
> 

Rob

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Karsten Fleischer]

> > Which pthread draft version do we have on Cygwin?  At least 8, I
> think...
> > Robert?
>
> The original work - I have no idea.

Me neither. I was just guessing. Assuming version 8 seems reasonable to me
(pthread_attr_setdetachstate is/will be implemented in Cygwin and
pthread_yield is called rather than sched_yield from OmniORB).

> I'm working of the documentation at www.opengroup.org (searching on
> google is the easiest way to a good entry point). They don't mention
> draft versions there.. I'm goping to have to dig up the current IEEE
> specs I can see.

Hmm, as I mentioned before I'm not very familiar with pthreads but somehow I
remember seeing the term "draft" in this context more than once. HP-UX
headers? Dunno. I'll do a quick search on the HP-UX and SunOS systems at
work tomorrow.

> If the project uses autoconf...

Nope. OmniORB doesn't use autoconf. You have to select your building system
manually. In case of Cygwin, you have to write your own makefile or derive
one from the existing ones.

Personally, I don't think that the Python issue (which was the start of this
thread) is the biggest problem in building OmniORB as it is shipped with a
prebuilt Python (with or without thread support, that shouldn't matter since
it is needed only for building OmniORB itself and the IDL compiler omniidl
uses it as a backend for output). It has always been the incomplete pthreads
or, mixing Cygwin/POSIX and Windows stuff. I might be wrong since it's about
nine months ago I tried to build OmniORB with Cygwin.
Bruno, could you try it out with the prebuilt Python?
I will make another attempt at compiling OmniORB as soon as Robert has put
in the missing parts into pthreads.

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

----- Original Message -----
From: "Fleischer, Karsten (K.)" <kfleisc1@getrag-ford.com>
To: <cygwin@cygwin.com>
Sent: Wednesday, April 04, 2001 10:37 PM
Subject: RE: port of omniorb


>
> I had a closer look at OmniORB's posix.cc source file.
>
Thank you.


> Which pthread draft version do we have on Cygwin?  At least 8, I
think...
> Robert?

The original work - I have no idea. I do know that some things were
quite different to what newlibc exports which has caused some confusion.

I'm working of the documentation at www.opengroup.org (searching on
google is the easiest way to a good entry point). They don't mention
draft versions there.. I'm goping to have to dig up the current IEEE
specs I can see.

You've done an excellent bit of research for me. It's my turn to plead
business - I'm hoping to get quite a bit done this weekend though, so
I'll actually read and cross reference what you've put together.

>
> So for building OmniORB one has to
> - undefine PthreadSupportThreadPriority
> - undefine NeedPthreadInit
> - define PthreadDraftVersion to 8(?)
> - undefine NoNanoSleep
> in the makefile.
>
> This is done by setting
> OMNITHREAD_POSIX_CPPFLAGS
= -UPthreadSupportThreadPriority -UNeedPthreadInit
> -DPthreadDraftVersion=8 -UNoNanoSleep
> in the platform specific makefile.
>
> The only change which is necessarily needed in posix.cc is to change
line
> 537 from
>
> #if !defined(__linux__)
>
> to
>
> #if !defined(__linux__) && !defined(__CYGWIN__)

If the project uses autoconf, that would be better tested as
#if HAVE_FEATURE

or even just have
#ifndef HAVE_FEATURE
#define func ;
#define func ;
#define func ;
#endif
in one of your core makefiles.
'course if it's not autoconf'd, what you've got is absolutely correct.

>
>
> Hope this helps...

It should. thank you.

>
> Karsten
>

Rob


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Fleischer, Karsten (K.)]

> X> pthread_detach (draft <= : arg is pthread_t *, otherwise pthread_t)

Oops, it should read "... draft <= 6 ...".

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Fleischer, Karsten (K.)]

I had a closer look at OmniORB's posix.cc source file.

There is a macro "PthreadSupportThreadPriority" which toggles use of thread
priority. If undefined,following functions are never needed:
> pthread_attr_setprio
> pthread_attr_setschedparam
> pthread_setprio
> pthread_setschedattr
> pthread_setschedparam


Here are the functions that are always needed:
X> pthread_cond_broadcast
X> pthread_cond_destroy
X> pthread_cond_signal
X> pthread_cond_timedwait
X> pthread_cond_wait
X> pthread_exit
O> pthread_setspecific
X> pthread_mutex_lock
X> pthread_mutex_unlock
X> pthread_self
X> pthread_mutex_destroy
X> pthread_join


The following are available on some OS's only. Alternatives for other OS's
are given, just have to choose the right one.
> pthread_get_expiration_np
> pthread_delay_np


These are used only if we have a pthread draft 4 implementation:
> pthread_attr_create
> pthread_attr_delete
??> pthread_keycreate

Otherwise these are used instead:
X> pthread_attr_destroy
X> pthread_attr_init
O> pthread_key_create


The following have different calling conventions along different versions of
the pthread draft:
X> pthread_create (draft 4: second arg is pthread_attr_t, otherwise
pthread_attr_t *)
X> pthread_detach (draft <= : arg is pthread_t *, otherwise pthread_t)
O> pthread_getspecific (draft <= 6: void return type, needs second arg of
type void **; draft > 6: void * return type, no second arg)
X> pthread_yield (if draft == 6: called with NULL arg, elif draft < 9: no
arg, else: call sched_yield)


These two are called with second arg = 0 for draft version != 4. With draft
version 4 the second arg is
pthread_mutexatrr_default/pthread_condattr_default:
X> pthread_cond_init
X> pthread_mutex_init


This one is used only if draft version == 8:
X> pthread_attr_setdetachstate


This one is used only if NeedPthreadInit is defined 
> pthread_init


This one, the only you marked as "can't be done", is used only if
!defined(__linux__)
C> pthread_attr_setstacksize


Which pthread draft version do we have on Cygwin?  At least 8, I think...
Robert?

Undefining the NoNanoSleep macro gets rid of pthread_delay_np. This forces
use of the nanosleep function instead in omni_thread::sleep.

Nothing has to be done to get rid of pthread_get_expiration_np. Use of
clock_gettime in omni_thread::get_time will happen automatically.

So for building OmniORB one has to
	- undefine PthreadSupportThreadPriority
	- undefine NeedPthreadInit
	- define PthreadDraftVersion to 8(?)
	- undefine NoNanoSleep
in the makefile.

This is done by setting
OMNITHREAD_POSIX_CPPFLAGS = -UPthreadSupportThreadPriority -UNeedPthreadInit
-DPthreadDraftVersion=8 -UNoNanoSleep
in the platform specific makefile.

The only change which is necessarily needed in posix.cc is to change line
537 from

#if !defined(__linux__)

to

#if !defined(__linux__) && !defined(__CYGWIN__)


Hope this helps...

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[bruno patin (travail)]

Hi,

I agree with you I think there is a bug. My question was not on what the 
definition of X_OK is but why it is as indicated by robert collins.

As a matter of fact, to end with mico, I only made the modification 
indicated in my other mail and the compilation posed no other problem. 
So I return to omniORB.


J. J. Farrell wrote:

>> From: "Robert Collins" <robert.collins@itdomain.com.au>
>> 
>>> From: bruno patin (travail) [ mailto:bruno.patin@wanadoo.fr ]
>>> 
>>> as a matter of fact, I'll speak of Mico. There is at least 
>>> one problem 
>>> with the porting. In the file mico/include/mico/os-misc.h, 
>>> there is in 
>>> an enumerate an initialisation with the value X_OK. But the file 
>>> unistd.h (in sys) define this value as : define X_OK 
>>> _cygwin_X_OK and it 
>>> is not an integer so you have an error at the compilation of 
>>> the file in 
>>> mico that include os-misc.h. I replace X_OK directly by the 
>>> value of one 
>>> (not a great feat and subject to other error I know). But what is the 
>>> meaning of this define of X_OK in cygwin ?
>> 
>> It's exported from libcygwin.a
>> (look in unistd.h - you should see
>> extern const unsigned _cygwin_X_OK;)
> 
> 
> That looks like an implementation bug - X_OK is supposed to be
> defined as a constant in <unistd.h>.
> 
> 
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
> 
> 
> 


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[J. J. Farrell]

> From: "Robert Collins" <robert.collins@itdomain.com.au>
> 
> > From: bruno patin (travail) [ mailto:bruno.patin@wanadoo.fr ]
> > 
> > as a matter of fact, I'll speak of Mico. There is at least 
> > one problem 
> > with the porting. In the file mico/include/mico/os-misc.h, 
> > there is in 
> > an enumerate an initialisation with the value X_OK. But the file 
> > unistd.h (in sys) define this value as : define X_OK 
> > _cygwin_X_OK and it 
> > is not an integer so you have an error at the compilation of 
> > the file in 
> > mico that include os-misc.h. I replace X_OK directly by the 
> > value of one 
> > (not a great feat and subject to other error I know). But what is the 
> > meaning of this define of X_OK in cygwin ?
> 
> It's exported from libcygwin.a
> (look in unistd.h - you should see
> extern const unsigned _cygwin_X_OK;)

That looks like an implementation bug - X_OK is supposed to be
defined as a constant in <unistd.h>.


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Karsten Fleischer]

> 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.

OK, I'll try it out. But I have to admit that I'm not too familiar with
pthreads. I'm having a day off tomorrow, so don't expect anything before,
hmm, Thursday, OK?

Karsten




--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Robert Collins]

> -----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

Re: port of omniorb

[Karsten Fleischer]

> 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


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Karsten Fleischer]

> This isn't what Robert asked.  He asked what is missing for your build.
> Robert is well aware of what is already existing as he is currently
> maintaining the PTHREAD routines for Cygwin.  He is trying to get
> information about what you need to add it to Cygwin on an as needed
> basis.  He doesn't have time to fit all of PTHREAD in the library all at
> once.

Earnie,
I'm quite aware that Robert can't do this spontanously.
As I said this was just a quick grep along the OmniORB sources.
And it was not me who asked for a build, I just wanted to share *my*
experiences on building OmniORB on Cygwin with you.
All I said was that OmniORB isn't usable with Cygwin at the moment, but once
pthreads are implemented with all the functions I grepped it should be quite
easy.

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Robert Collins]

> -----Original Message-----
> From: bruno patin (travail) [ mailto:bruno.patin@wanadoo.fr ]
> Sent: Tuesday, April 03, 2001 8:37 AM
> To: groupe cygwin
> Subject: Re:port of omniorb
> 
> 
> as a matter of fact, I'll speak of Mico. There is at least 
> one problem 
> with the porting. In the file mico/include/mico/os-misc.h, 
> there is in 
> an enumerate an initialisation with the value X_OK. But the file 
> unistd.h (in sys) define this value as : define X_OK 
> _cygwin_X_OK and it 
> is not an integer so you have an error at the compilation of 
> the file in 
> mico that include os-misc.h. I replace X_OK directly by the 
> value of one 
> (not a great feat and subject to other error I know). But what is the 
> meaning of this define of X_OK in cygwin ?
> 

It's exported from libcygwin.a
(look in unistd.h - you should see
extern const unsigned _cygwin_X_OK;)

Rob

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

----- Original Message -----
From: "Jason Tishler" <Jason.Tishler@dothill.com>
To: "Robert Collins" <robert.collins@itdomain.com.au>
Cc: "bruno patin (travail)" <bruno.patin@wanadoo.fr>; "groupe cygwin"
<cygwin@cygwin.com>
Sent: Tuesday, April 03, 2001 7:02 AM
Subject: Re: port of omniorb


> Rob,
>
>
> Although ORBit has C++ bindings and POA support now (it didn't a year
> ago), it still only claims CORBA 2.2 compliance.  We are looking for
> CORBA 2.3 compliance along with the Trading and Event services which
> still seem to be missing.
>
> Thanks,
> Jason
>

Ah well... it was worth a thought.

Rob


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

----- Original Message -----
From: "Fleischer, Karsten (K.)" <kfleisc1@getrag-ford.com>
To: "'Robert Collins'" <robert.collins@itdomain.com.au>;
<cygwin@cygwin.com>
Sent: Tuesday, April 03, 2001 1:49 AM
Subject: RE: port of omniorb


> > What's missing in the pthread implementation? Give me a direction or
> > particular function list and I'll see what I can do.
>
> A quick grep on the posix.cc source file gives the following
functions:

Thanks.
    Are they all critical, or are any of them tested for?


I've marked below the status (from memory - it's not gospel) of cygwin.
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.

I suspect that some of your closely named function there are #if tested
across several platforms (ie whats the difference betwen
pthread_attr_delete and _destroy?

I'm going to make an effort this week to get a backlogged patch tidied
up and resubmitted which will cover the functions marked O, I'll post
here once that's in a snapshot.

IMO that should make your program compilable and useable (it may not
have relative priorities between threads, but that should not be a
showstopper.

Rob

> pthread_attr_create
> pthread_attr_delete
X> pthread_attr_destroy
X> pthread_attr_init
X> pthread_attr_setdetachstate
> pthread_attr_setprio
> pthread_attr_setschedparam
C> pthread_attr_setstacksize
X> pthread_cond_broadcast
X> pthread_cond_destroy
X> pthread_cond_init
X> pthread_cond_signal
X> pthread_cond_timedwait
X> pthread_cond_wait
X> pthread_create
> pthread_delay_np
X> pthread_detach
X> pthread_exit
> pthread_get_expiration_np
O> pthread_getspecific
> pthread_init
X> pthread_join
O> pthread_key_create
?? typo ??> pthread_keycreate
X> pthread_mutex_destroy
X> pthread_mutex_init
X> pthread_mutex_lock
X> pthread_mutex_unlock
X> pthread_self
> pthread_setprio
> pthread_setschedattr
> pthread_setschedparam
O> pthread_setspecific
X> pthread_yield
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[bruno patin (travail)]

My first compilation gives me an error on the dii.cc. It declares
that :

in mico/include/mico/os-misc.h at line 217 : enumerator value for 
ACCESS_EXEC not integer constant

strange because the initalisation is made by X_OK a classical define.

thanks for your help

edward wrote:

> ----- Original Message -----
> From: "Jason Tishler" <Jason.Tishler@dothill.com>
> To: "bruno patin (travail)" <bruno.patin@wanadoo.fr>
> Cc: "groupe cygwin" <cygwin@cygwin.com>
> Sent: Sunday, April 01, 2001 12:37 AM
> Subject: Re: port of omniorb
> 
> 
>> Check out MICO (www.mico.org), they have or had a Cygwin (b19) port.
>> Since, they do use autoconf, it may be as simple as:
>> 
>>     $ configure
>>     $ make
>>     $ make install
>> 
>> Then again, it may not...
>> 
> 
> Turned out, it *was* that easy, modulo some bug fixes in the demo suite
> (redlich/calc-{2,3,4} uses a reference, when it should use a pointer). the
> source itself works as far as i can tell, in the very limited time i've
> looked at it. at least well enough so that the demo source runs.
> 
> p.s. i didn't bother generating dlls. i used static compilations.
> 
> mico-2.3.5
> 
> cheers,
> edward
> 
> 
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
> 
> 
> 


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Jason Tishler]

Edward,

On Mon, Apr 02, 2001 at 02:28:34AM -0400, edward wrote:
> ----- Original Message -----
> From: "Jason Tishler" <Jason.Tishler@dothill.com>
> To: "bruno patin (travail)" <bruno.patin@wanadoo.fr>
> Cc: "groupe cygwin" <cygwin@cygwin.com>
> Sent: Sunday, April 01, 2001 12:37 AM
> Subject: Re: port of omniorb
> 
> 
> > Check out MICO (www.mico.org), they have or had a Cygwin (b19) port.
> > Since, they do use autoconf, it may be as simple as:
> >
> >     $ configure
> >     $ make
> >     $ make install
> >
> > Then again, it may not...
> >
> 
> Turned out, it *was* that easy, modulo some bug fixes in the demo suite
> (redlich/calc-{2,3,4} uses a reference, when it should use a pointer). the
> source itself works as far as i can tell, in the very limited time i've
> looked at it. at least well enough so that the demo source runs.

I had hoped so -- thanks for confirming it.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Jason Tishler]

Rob,

On Sun, Apr 01, 2001 at 03:25:02PM +1000, Robert Collins wrote:
> Uhmm , ORBit-0.5.3 compiled pretty much OOTB and ran smoothly for me
> when I first started looking at GNOME on cygwin. Does that cover the
> CORBA requirements you've got?

Although ORBit has C++ bindings and POA support now (it didn't a year
ago), it still only claims CORBA 2.2 compliance.  We are looking for
CORBA 2.3 compliance along with the Trading and Event services which
still seem to be missing.

Thanks,
Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Fleischer, Karsten (K.)]

> What's missing in the pthread implementation? Give me a direction or
> particular function list and I'll see what I can do.

A quick grep on the posix.cc source file gives the following functions:

pthread_attr_create
pthread_attr_delete
pthread_attr_destroy
pthread_attr_init
pthread_attr_setdetachstate
pthread_attr_setprio
pthread_attr_setschedparam
pthread_attr_setstacksize
pthread_cond_broadcast
pthread_cond_destroy
pthread_cond_init
pthread_cond_signal
pthread_cond_timedwait
pthread_cond_wait
pthread_create
pthread_delay_np
pthread_detach
pthread_exit
pthread_get_expiration_np
pthread_getspecific
pthread_init
pthread_join
pthread_key_create
pthread_keycreate
pthread_mutex_destroy
pthread_mutex_init
pthread_mutex_lock
pthread_mutex_unlock
pthread_self
pthread_setprio
pthread_setschedattr
pthread_setschedparam
pthread_setspecific
pthread_yield


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

----- Original Message -----
From: "Fleischer, Karsten (K.)" <kfleisc1@getrag-ford.com>
To: <cygwin@cygwin.com>
Sent: Tuesday, April 03, 2001 12:36 AM
Subject: RE: port of omniorb


>
> > I too briefly looked into building a Cygwin omniorb.  But,
> > when I realized
> > that they did not support the CORBA 2.3 spec (i.e., POA) and that
they
> > did *not* use autoconf, I elected not to spend the time to attempt
the
> > port.
>
> OmniORB 3 supports POA. However it is not yet completely CORBA 2.3
> compliant. In the README they say:
>
snip
>
> Once the Cygwin pthread implementation is stable one might give it a
try,
> starting off with unix.mk makefile.

What's missing in the pthread implementation? Give me a direction or
particular function list and I'll see what I can do.

Rob

>
> Karsten
>
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

RE: port of omniorb

[Fleischer, Karsten (K.)]

> I too briefly looked into building a Cygwin omniorb.  But, 
> when I realized
> that they did not support the CORBA 2.3 spec (i.e., POA) and that they
> did *not* use autoconf, I elected not to spend the time to attempt the
> port.

OmniORB 3 supports POA. However it is not yet completely CORBA 2.3
compliant. In the README they say:

-->8--
omniORB3 is not yet a complete implementation of the CORBA core. The
following features are not supported in the current release.

- Support for IDL type longlong, longdouble, wchar, wstring, fixed,
  valuetype

-->8--

> I found it ironic that they required Cygwin to build their Win32
> version but they did not have a Cygwin version.  Searching their
> archives, I found that someone asked how to build a Cygwin version in
> the past.  Unfortunately, no one ever responded.

They do not require a complete Cygwin to build. They require gmake, a
/bin/sh and  some tools (cp, mv, rm, I think). They provide wrappers around
the MSVC compiler, archiver and linker.

I believe the main reason that there isn't a Cygwin version of OmniORB is
that Cygwin's pthread support isn't finished yet. They use native Windows
threads instead. There's a lot of #ifdef __WIN32__ stuff in the sources.
But, you can't compile it with the -mno-cygwin option, because it's written
in C++. And this is turn the reason why you can't use the precompiled
OmniORB libraries for linking with GCC (different name mangling schemes).
Sigh...
So if you'd carefully tweak those #ifdef's I think you could build a Cygwin
version. I tried it once but gave up...

Once the Cygwin pthread implementation is stable one might give it a try,
starting off with unix.mk makefile.

Karsten


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[edward]

----- Original Message -----
From: "Jason Tishler" <Jason.Tishler@dothill.com>
To: "bruno patin (travail)" <bruno.patin@wanadoo.fr>
Cc: "groupe cygwin" <cygwin@cygwin.com>
Sent: Sunday, April 01, 2001 12:37 AM
Subject: Re: port of omniorb


> Check out MICO (www.mico.org), they have or had a Cygwin (b19) port.
> Since, they do use autoconf, it may be as simple as:
>
>     $ configure
>     $ make
>     $ make install
>
> Then again, it may not...
>

Turned out, it *was* that easy, modulo some bug fixes in the demo suite
(redlich/calc-{2,3,4} uses a reference, when it should use a pointer). the
source itself works as far as i can tell, in the very limited time i've
looked at it. at least well enough so that the demo source runs.

p.s. i didn't bother generating dlls. i used static compilations.

mico-2.3.5

cheers,
edward


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Robert Collins]

Uhmm , ORBit-0.5.3 compiled pretty much OOTB and ran smoothly for me
when I first started looking at GNOME on cygwin. Does that cover the
CORBA requirements you've got?

Rob


----- Original Message -----
From: "Jason Tishler" <Jason.Tishler@dothill.com>
To: "bruno patin (travail)" <bruno.patin@wanadoo.fr>
Cc: "groupe cygwin" <cygwin@cygwin.com>
Sent: Sunday, April 01, 2001 2:37 PM
Subject: Re: port of omniorb


> Bruno,
>
> On Sat, Mar 31, 2001 at 11:11:18AM +0200, bruno patin (travail) wrote:
> > I did it before and it compile. But in the port of omniorb itself,
the
> > omniidl command needs some Python software that it can't see. I
wrote to
> > the omniorb mailing list and they ask me if cygwin could create .so
> > libraries. I didn't observe the gcc -shared command but I think you
made
> > it identical with the other gcc on the other platforms.
>
> Cygwin gcc supports -shared and can create shared libraries (i.e.,
> DLLs).  Although, following Windows conventions they usually end it
> ".dll" instead ".so".
>
> Can you point me toward the above mentioned response from the omniorb
> list?  I would like to read it.
>
> > They ask for knowing which platform to choose for the compilation as
the
> > cygwin one doesn't exist.  I took the glibc2.1 platform. Do you
think it
> > is right (I regard the gcc version for this choice).
>
> Sorry, I don't know the answer the above.  I wish that I did,
because...
>
> I too briefly looked into building a Cygwin omniorb.  But, when I
realized
> that they did not support the CORBA 2.3 spec (i.e., POA) and that they
> did *not* use autoconf, I elected not to spend the time to attempt the
> port.
>
> I found it ironic that they required Cygwin to build their Win32
> version but they did not have a Cygwin version.  Searching their
> archives, I found that someone asked how to build a Cygwin version in
> the past.  Unfortunately, no one ever responded.
>
> > My choices :
> >
> > to return to the python compiling and introduce a correct support
thread
> > to use the native win32 omniorb implementation (is it possible and
how)
> > to use another orb that is already ported on cygwin (do you know
one)
>
> Check out MICO (www.mico.org), they have or had a Cygwin (b19) port.
> Since, they do use autoconf, it may be as simple as:
>
>     $ configure
>     $ make
>     $ make install
>
> Then again, it may not...
>
> > As it is essential to my work I'm ready to make this effort as I
think
> > it is really interesting to have a Broker present and native for the
> > cygwin platform in order to further banalize the windows os inside
unix
> > environment (as a matter of fact your work is really good).
>
> I would like to see a Cygwin CORBA ORB too.  If you are willing to
tackle
> the omniorb side, then I'm willing to help you with the Cygwin Python
side,
> if necessary.
>
> Jason
>
> --
> Jason Tishler
> Director, Software Engineering       Phone: +1 (732) 264-8770 x235
> Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
> 82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
> Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com
>
> --
> Want to unsubscribe from this list?
> Check out: http://cygwin.com/ml/#unsubscribe-simple
>
>


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Jason Tishler]

Bruno,

On Sat, Mar 31, 2001 at 11:11:18AM +0200, bruno patin (travail) wrote:
> I did it before and it compile. But in the port of omniorb itself, the 
> omniidl command needs some Python software that it can't see. I wrote to 
> the omniorb mailing list and they ask me if cygwin could create .so 
> libraries. I didn't observe the gcc -shared command but I think you made 
> it identical with the other gcc on the other platforms.

Cygwin gcc supports -shared and can create shared libraries (i.e.,
DLLs).  Although, following Windows conventions they usually end it
".dll" instead ".so".

Can you point me toward the above mentioned response from the omniorb
list?  I would like to read it.

> They ask for knowing which platform to choose for the compilation as the
> cygwin one doesn't exist.  I took the glibc2.1 platform. Do you think it
> is right (I regard the gcc version for this choice).

Sorry, I don't know the answer the above.  I wish that I did, because...

I too briefly looked into building a Cygwin omniorb.  But, when I realized
that they did not support the CORBA 2.3 spec (i.e., POA) and that they
did *not* use autoconf, I elected not to spend the time to attempt the
port.

I found it ironic that they required Cygwin to build their Win32
version but they did not have a Cygwin version.  Searching their
archives, I found that someone asked how to build a Cygwin version in
the past.  Unfortunately, no one ever responded.

> My choices :
> 
> to return to the python compiling and introduce a correct support thread
> to use the native win32 omniorb implementation (is it possible and how)
> to use another orb that is already ported on cygwin (do you know one)

Check out MICO (www.mico.org), they have or had a Cygwin (b19) port.
Since, they do use autoconf, it may be as simple as:

    $ configure
    $ make
    $ make install

Then again, it may not...

> As it is essential to my work I'm ready to make this effort as I think 
> it is really interesting to have a Broker present and native for the 
> cygwin platform in order to further banalize the windows os inside unix 
> environment (as a matter of fact your work is really good).

I would like to see a Cygwin CORBA ORB too.  If you are willing to tackle
the omniorb side, then I'm willing to help you with the Cygwin Python side,
if necessary.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[bruno patin (travail)]

First, thanks for your help,

Jason Tishler wrote:

> Bruno,
> 
> On Fri, Mar 30, 2001 at 10:20:33PM +0200, bruno patin (travail) wrote:
> 
>> I try to port omniorb on the cygwin platform. To do this, I'm first 
>> porting python. I don't know why but I can't compile python with the 
>> thread support and so I have problems with omniorb. Has someone 
>> attempted such a thing.
> 
> 
> I noticed a while ago that omniorb needed Python to build their toolset.
> Are you sure that you need a Python with threading or just the ability
> to run Python scripts?  If the latter, then note that Python 2.1b2 builds
> OOTB under Cygwin if you configure as follows:
> 
>     $ configure --with-threads=no

I did it before and it compile. But in the port of omniorb itself, the 
omniidl command needs some Python software that it can't see. I wrote to 
the omniorb mailing list and they ask me if cygwin could create .so 
libraries. I didn't observe the gcc -shared command but I think you made 
it identical with the other gcc on the other platforms. They ask for 
knowing which platform to choose for the compilation as the cygwin one 
doesn't exist. I took the glibc2.1 platform. Do you think it is right (I 
regard the gcc version for this choice).

My choices :

to return to the python compiling and introduce a correct support thread
to use the native win32 omniorb implementation (is it possible and how)
to use another orb that is already ported on cygwin (do you know one)

As it is essential to my work I'm ready to make this effort as I think 
it is really interesting to have a Broker present and native for the 
cygwin platform in order to further banalize the windows os inside unix 
environment (as a matter of fact your work is really good).

> 
> 
> Sorry, but Cygwin Python's support of threads is not ready for prime
> time.
> 
> Jason
> 
Thanks a lot


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Jason Tishler]

Bruno,

On Fri, Mar 30, 2001 at 10:20:33PM +0200, bruno patin (travail) wrote:
> I try to port omniorb on the cygwin platform. To do this, I'm first 
> porting python. I don't know why but I can't compile python with the 
> thread support and so I have problems with omniorb. Has someone 
> attempted such a thing.

I noticed a while ago that omniorb needed Python to build their toolset.
Are you sure that you need a Python with threading or just the ability
to run Python scripts?  If the latter, then note that Python 2.1b2 builds
OOTB under Cygwin if you configure as follows:

    $ configure --with-threads=no

Sorry, but Cygwin Python's support of threads is not ready for prime
time.

Jason

-- 
Jason Tishler
Director, Software Engineering       Phone: +1 (732) 264-8770 x235
Dot Hill Systems Corp.               Fax:   +1 (732) 264-8798
82 Bethany Road, Suite 7             Email: Jason.Tishler@dothill.com
Hazlet, NJ 07730 USA                 WWW:   http://www.dothill.com

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

Re: port of omniorb

[Larry Hall (RFK Partners, Inc)]

At 03:20 PM 3/30/2001, bruno patin (travail) wrote:
>Hi all,
>
>I try to port omniorb on the cygwin platform. To do this, I'm first porting python. I don't know why but I can't compile python with the thread support and so I have problems with omniorb. Has someone attempted such a thing.
>
>As a matter of fact, I really want to port my programs that use omniorb but I don't know how to use directly the windows dll of omniorb directly with a complation of my programs.



Cygwin has limited thread support, although allot of work has been done on 
it recently.  See the messages from Rob Collins in the email archives over 
the last couple of weeks to get yourself familiar with what's there (or
look at the source if you dare!;-)).



Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

port of omniorb

[bruno patin (travail)]

Hi all,

I try to port omniorb on the cygwin platform. To do this, I'm first 
porting python. I don't know why but I can't compile python with the 
thread support and so I have problems with omniorb. Has someone 
attempted such a thing.

As a matter of fact, I really want to port my programs that use omniorb 
but I don't know how to use directly the windows dll of omniorb directly 
with a complation of my programs.

thanks for the help.


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple