RE: Building 3.14.1 under cygwin environment

["Jeff Hill" <johill@lanl.gov>]

Chris,

I suspect that your problem with fd_set below is caused by side
effects in the cygwin header files occurring when POSIX_SOURCE
was being defined in CONFIG.Common.win32-x86-cygwin. Some time
back, for lack of a better idea, I removed the definition of
POSIX_SOURCE there but I must confess that I don't know the full
impact of that change.

Executive summary: 
The latest snapshot of EPICS R3.14 is building with cygwin, but
there are still some significant problems detected by the
regression tests. It's possible that these problems could be
resolved with some further effort in the debugger. 

I should add however that the performance of the cygwin layered
approach compared to the native windows port is significantly
worse, and there are some good quality free native windows
targeting compilers such as Borland bcc and gnu gcc if you are
opposed to buying the MS compiler, and you don't need a POSIX
compatibility layer for windows.

I am attaching some messages I sent to Janet awhile back with the
latest status on my efforts to get R3.14 to work with cygwin.
Since that message was sent I have made changes in the
organization of the code that permit avoidance of use of the
broken signaling features of cygwin to interrupt blocking recv()
and send() calls. I currently have the cygwin interface
configured to use shutdown() for this purpose, but I have not yet
confirmed that this is working. 

>   Thanks for the tips I'll give that a try. Does anyone know
> the answer to Eric's question about win98

The answer is that the native windows interface of EPICS R3.14
does link with one function that is available only in NT/2000/XP.
However if you use delayed binding of the DLL's then the code
should successfully detect 95/98/ME and avoid calling this
function. The function involved is TryEnterCriticalSection and
its use permits significantly improved performance on NT/2000/XP.
Given the marginal reliability of 95/98/ME then their use should
probably be avoided in production systems.

The cygwin interface of EPICS R3.14 is another matter. This is
purely dependent on cygwin which probably addresses its windows
version compatibility range within its documentation.

Jeff

> -----Original Message-----
> From: cjm@observatorysciences.co.uk
> [mailto:cjm@observatorysciences.co.uk]
> Sent: Monday, April 28, 2003 5:25 AM
> To: Eric Norum
> Cc: tech-talk@aps.anl.gov
> Subject: Re: Building 3.14.1 under cygwin environment
> 
> Eric Norum wrote:
> 
> > What I usually do in situations like this is to issue the
> compile
> > command with -c changed to -E so I can see exactly what's
> getting passed
> >   on from the preprocessor to the compiler.  The offending
> line is:
> >      fd_set fdSets[fdrNEnums];
> > This makes me think that the likely cause of the problem is
> that
> > 1) fd_set is not typefed properly.  (to check, run the output
> of the
> > '-E' compile through 'grep fd_set'.
> > OR
> > 2) fdSets is being defined as a preprocessor macro somewhere
> in some
> > cygwin header file.  About the only thing to do here is to
> 'grep fdSets'
> > on all the header files.
> >
> > BTW -- is EPICS likely to work on win98???
> >
> 
>   Thanks for the tips I'll give that a try. Does anyone know
> the answer
> to Eric's question about win98 ? This is my first foray into
> running
> Epics/Channel Access from a Windows environment so any help
> would be
> appreciated. Also, does anyone know what the situation is with
> XP ?
> 
>       Chris Mayer
> _______________________________________________________________
> ________
> Observatory Sciences Ltd.          Email:
> cjm@observatorysciences.co.uk
> William James House                Tel: 44 - (0)1223 - 508257
> Cowley Road,                       Fax: 44 - (0)1223 - 508258
> Cambridge, CB4 0WX, UK
> http://www.observatorysciences.co.uk

--- Begin Message ---

Subject:	cygwin
From:	"Jeff Hill" <johill@lanl.gov>
To:	"Janet Anderson" <jba@aps.anl.gov>
Cc:	"'Marty Kraimer'" <mrk@aps.anl.gov>
Date:	Thu, 20 Mar 2003 19:30:48 -0600

Title: cygwin

Hi,

The situation with R3.14 and cygwin looks grim. There is also this problem that looks like a bug in the cygwin POSIX signals. It appears that cygwin does work with R3.14, but not very well.

Program received signal SIGSEGV, Segmentation fault.
[Switching to thread 2036.0x6ec]
0x6107454d in sigaction () from /usr/bin/cygwin1.dll
(gdb) where
#0  0x6107454d in sigaction () from /usr/bin/cygwin1.dll
#1  0x004381db in localInstallSigHandler(int, void (*)(int), void (*)(int)*) (si
gnalIn=16, pNewFunc=0x43831e <ignoreSigUrg>, pReplacedFunc=0x4853e4) at ../../..
/src/libCom/osi/os/posix/osdSignal.cpp:41
#2  0x00438382 in epicsSignalInstallSigUrgIgnore () at ../../../src/libCom/osi/o
s/posix/osdSignal.cpp:101
#3  0x004371e1 in epicsEnableInterruptedSystemCall () at ../../../src/libCom/osi
/osiSock.c:173
#4  0x0041dd64 in tcpSendThread::run() (this=0xa05eaa8) at ../tcpiiu.cpp:68
#5  0x0043910a in epicsThreadCallEntryPoint (pPvt=0xa05eaac) at ../../../src/lib
Com/osi/epicsThread.cpp:39
#6  0x0043263b in start_routine (arg=0xa05f288) at ../../../src/libCom/osi/os/po
six/osdThread.c:271
#7  0x6108bf81 in cygwin1!cfsetispeed () from /usr/bin/cygwin1.dll
#8  0x77e8b2d8 in lstrcmpiW () from /cygdrive/c/WINNT/system32/KERNEL32.DLL

(gdb) up
#1  0x004381db in localInstallSigHandler(int, void (*)(int), void (*)(int)*) (si
gnalIn=16, pNewFunc=0x43831e <ignoreSigUrg>, pReplacedFunc=0x4853e4) at ../../..
/src/libCom/osi/os/posix/osdSignal.cpp:41
41          status = sigaction ( signalIn, & newAction, & oldAction );
Current language:  auto; currently c++
 (gdb) print signalIn
$1 = 16
(gdb) print & newAction
$2 = (sigaction *) 0x271f20c
(gdb) print & oldAction
$3 = (sigaction *) 0x271f1fc
(gdb) up
#2  0x00438382 in epicsSignalInstallSigUrgIgnore () at ../../../src/libCom/osi/o
s/posix/osdSignal.cpp:101
101         localInstallSigHandler ( SIGURG,
(gdb) down
#1  0x004381db in localInstallSigHandler(int, void (*)(int), void (*)(int)*) (si
gnalIn=16, pNewFunc=0x43831e <ignoreSigUrg>, pReplacedFunc=0x4853e4) at ../../..
/src/libCom/osi/os/posix/osdSignal.cpp:41
41          status = sigaction ( signalIn, & newAction, & oldAction );
(gdb) print newAction
$4 = {sa_handler = 0x43831e <ignoreSigUrg>, sa_mask = 0, sa_flags = 0}

Jeff
__________________________________________________________
Jeffrey O. Hill               Mail         JOHill@lanl.gov
LANL MS H820                  Voice        505 665 1831
Los Alamos NM 87545 USA       Fax          505 665 5107

--- End Message ---

--- Begin Message ---

Subject:	cygwin and R3.14
From:	"Jeff Hill" <johill@lanl.gov>
To:	"Janet Anderson" <jba@aps.anl.gov>
Cc:	"Marty Kraimer" <mrk@aps.anl.gov>, "'Bob Dalesio'" <dalesio@lanl.gov>
Date:	Thu, 20 Mar 2003 16:36:34 -0600

Title: cygwin and R3.14

Hi Janet,

I now have the R3.14 cygwin build running start to finish and many tests are passing. I committed the changes. I included Marty here because this is a POSIX port and because of (2) below.

The primary changes were:

o If POSIX_SOURCE is defined then support for select() disappears so I currently have it undefined, but Marty may have some suggestions. I remember that Solaris used to be somewhat the same way and that it was nearly impossible to use sockets if you set _POSIX_SOURCE.

o If -ansi is defined then an optimized build fails because Andrew's list test fails to compile lacking a strdup() prototype.

o Cygwin does not appear to have clock_gettime() so I substituted gettimeofday().

o I removed some junk from cygwin's osdSock.h that are no longer needed with modern versions of cygwin.

Some remaining issues that I have seen during limited testing:

1) The epicsTimerTestHost produces poor timer accuracy results compared to native windows. This may be caused by a problem in cygwin.

2) There are funny messages when I run catime.

     31 [unknown (0x838)] catime 2048 pthread_cond::Signal: Released too many threads - 1 now 1 originally
 170138 [unknown (0x838)] catime 2048 pthread_cond::Signal: Released too many threads - 1 now 1 originally
 638979 [unknown (0x838)] catime 2048 pthread_cond::Signal: Released too many threads - 1 now 1 originally

3) I was somewhat surprised to discover that the arch name is win32-x86-cygwin instead of cygwin-x86 since cygwin is probably best described as another POSIX variant.

4) The performance of CA initially looks very poor through the cygwin interface (compared to win32 direct) possibly because of a slow implementation of epicsMutex on cygwin. This is a wild guess at this point that is partially backed up by the low performance measured by epicsMutexTest.

5) Many things related to CA are working, but the regression tests are failing in a strange way that looks suspiciously like problems with a proper implementation of the connect() call on cygwin.

Jeff
__________________________________________________________
Jeffrey O. Hill               Mail         JOHill@lanl.gov
LANL MS H820                  Voice        505 665 1831
Los Alamos NM 87545 USA       Fax          505 665 5107

--- End Message ---