EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: EPICS on Tru64unix and HP-UX
From: Kazuro FURUKAWA <[email protected]>
To: Andrew Johnson <[email protected]>
Cc: Kazuro FURUKAWA <[email protected]>, [email protected], EPICS core-talk <[email protected]>, Jeff Hill <[email protected]>
Date: Thu, 21 Dec 2006 07:53:45 +0900
Hello Andrew, 

Thank you for detailed investigation. 

>>> On Wed, 20 Dec 2006 16:05:53 JST,  Andrew Johnson <[email protected]> wrote;
> Hi Kazuro,
> 
> Kazuro FURUKAWA wrote:
> > For Tru64unix...
> 
> > [1] comBuf.h
> > I've tried it again without comBuf.h modification.  And I've got 
> > the following error.  I've changed the compiler features like 
> > -std {gun,ansi,ms,arm} and they gave me the same results.  I don't 
> > know why the error occurs, and why my change cures the compilation. 
> > 
> > =====
> > cxx  -c           -D_OSF_SOURCE -DUNIX   -std gnu -pthread -ieee  -O            
> > -I. -I.. -I../../../include/os/osf -I../../../include         ../comQueSend.cpp 
> > cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
> >           variable "tmp" of incomplete type "WireAlias<const char *>".
> >           detected during:
> >             instantiation of "void WireSet(const T &, epicsUInt8 *) [with
> >                       T=const char *]" at line 191 of "../comBuf.h"
> >             instantiation of
> >                       "bool comBuf::push(const T &) [with T=const char *]" at
> >                       line 144 of "../comQueSend.h"
> >             instantiation of
> >                       "void comQueSend::push(const T &) [with T=const char *]"
> >                       at line 112 of "../comQueSend.cpp"
> >     WireAlias < T > tmp;
> > --------------------^
> > cxx: Warning: ../comQueSend.cpp, line 327: pointless comparison of unsigned
> >           integer with zero
> >     if ( INVALID_DB_REQ ( dataType ) ) {
> > ---------^
> > cxx: Info: 1 error detected in the compilation of "../comQueSend.cpp".
> > =====
> > 
> > I've put the full compilation log with above error at 
> > <URL:http://www-linac.kek.jp/jk/osf/base-3.14.9pr2-make-osf-failed.log>
> 
> Ok, I'm still waiting for a comment from Jeff Hill on your patch and/or 
> the above compile error - we committed all of your other changes, but 
> this is Jeff's code so he gets to decide what to do about it.

I understand.  The patch I added is nasty... There should be better 
approach. 

> > [2] snprintf()
> > It seems the definition of the return value is different on Tru64. 
> > It simply returns the length of the buffer.  The buffer contents 
> > are OK.  The part of the results is like this. 
> > =====
> > not ok  1 - epicsSnprintf(size=1) = 0
> > ok  2 - buffer = ''
> > ok  3 - length = 0
> > not ok  4 - epicsSnprintf(size=2) = 1
> > ok  5 - buffer = 'i'
> > ok  6 - length = 1
> > =====
> > The return value should be 46.  We may include a version of free 
> > snprintf() into the source tree, but... 
> 
> According to the C99 standard the return value from snprintf() is 
> supposed to be the number of characters that would have been written to 
> the buffer if it were large enough.  We're used to different operating 
> systems having different semantics for snprintf(), which is why we make 
> it possible for each architecture to implement their own workaround.
> 
> I'm not aware of any code in Base that will fail with the above issue, 
> but it would be good to fix this sometime - I won't hold up the R3.14.9 
> release waiting for it though.

The document on Tru64unix says the current behavior.  Thus, it is a 
feature, not a bug.  They may have misunderstood the standard, or 
have followed a draft standard. 

I'm thinking about a dirty wrapper around their vsnprintf(), if I 
have time. 

> > [3] timer
> > An example of the errore is like this. 
> > =====
> > ./epicsTimerTest
> > 1..33
> > # Testing timer accuracy
> > not ok  1 - percentError < messageThresh
> > # delay = 1.000000 s, error = -0.007792 s (0.8 %)
> > not ok  2 - percentError < messageThresh
> > # delay = 1.100000 s, error = -0.007204 s (0.7 %)
> > not ok  3 - percentError < messageThresh
> > # delay = 1.200000 s, error = -0.007592 s (0.6 %)
> > not ok  4 - percentError < messageThresh
> > # delay = 1.300000 s, error = -0.007981 s (0.6 %)
> > not ok  5 - percentError < messageThresh
> > # delay = 1.400000 s, error = -0.007393 s (0.5 %)
> > not ok  6 - percentError < messageThresh
> > # delay = 1.500000 s, error = -0.007781 s (0.5 %)
> > not ok  7 - percentError < messageThresh
> > # delay = 1.600000 s, error = -0.008170 s (0.5 %)
> > ok  8 - percentError < messageThresh
> 
> > Without load, software with usleep() or setitimer() normally shows 
> > 0-2 millisecond accuracy.  So the above discrepancies are large 
> > compared with my experiences.  We have 7 alpha machines at KEKB 
> > and Linac.  The numbers of processes are 200 to 600, and the load 
> > averages are 1 to 15.  The results do not change much between 
> > machines.  I don't know the origin of the errors. 
> 
> I regard the earlier timer tests not so much as an error as a warning, 
> and since your machines are running signficant numbers of processes I 
> would not be too worried by the above failures.

[4] LDLIBS
I realized another inconsistency, as I tried R3.14-CVS dated 
Dec.20 for native compiler (namely osf-alpha, instead of osf-alpha-gnu).
I should have used the flag -pthread instead of "-D_REENTRANT 
-lpthread ..." consistently for cc and ld. 
The rule is correctly followed for STRICT targets but not for 
others.  
Also as a side effect(?) -lm is not used in OP_SYS_LDLIBS for some 
targets.  epicsCalcTest for example fails to build with CVS-source.  
I had put "USR_SYS_LIBS += m" in CONFIG.Common.osf-alpha as a 
work-around in my patch, but maybe that is not clean.  I may look 
in more although I don't yet understand when OP_SYS_LDLIBS is 
overwritten. 
  
Cheers.
-----
Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321


Replies:
RE: EPICS on Tru64unix and HP-UX Jeff Hill
References:
Re: EPICS on Tru64unix and HP-UX Andrew Johnson

Navigate by Date:
Prev: Re: EPICS on Tru64unix and HP-UX Andrew Johnson
Next: RE: EPICS on Tru64unix and HP-UX Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS on Tru64unix and HP-UX Andrew Johnson
Next: RE: EPICS on Tru64unix and HP-UX Jeff Hill
Index: 2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Feb 2012 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·