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: "Jeff Hill" <[email protected]>
Cc: [email protected], "'Andrew Johnson'" <[email protected]>, [email protected], "'EPICS core-talk'" <[email protected]>
Date: Sat, 23 Dec 2006 10:03:50 +0900
Hello Jeff, 

I've look in cvsweb at aps and the file is dated Dec.21 22:15 GMT. 
<http://www.aps.anl.gov/cgi-bin/epics/cvsweb/>
<http://www.aps.anl.gov/cgi-bin/epics/cvsweb/base/src/libCom/osi/os/default/osdWireFormat.h>
I'll watch it to update. 

In the mean time I've modified configure scripts.  I'll send to 
Andrew. 

Cheers.

>>> On Fri, 22 Dec 2006 15:08:44 JST,  "Jeff Hill" <[email protected]> wrote;
> Kazuro,
> 
> I just noticed a few minutes ago a compile time error when building with =
> g++
> Linux. I committed a fix for this problem which may resolve your =
> troubles
> also.
> 
> Jeff
> 
> > -----Original Message-----
> > From: [email protected] [mailto:[email protected]]
> > Sent: Friday, December 22, 2006 1:52 PM
> > To: Jeff Hill
> > Cc: [email protected]; 'Andrew Johnson'; [email protected];
> > 'EPICS core-talk'
> > Subject: Re: EPICS on Tru64unix and HP-UX
> >=20
> > Hello Jeff,
> >=20
> > Sorry for my late reply.  I've got
> >   <http://www.aps.anl.gov/epics/download/base/base_R3-14_cvs.tar.gz>
> > dated Dec.22 06:07 GMT which include your patch, which gives
> > errors in comQueSend.cpp as the following log.  And again with my
> > dirty patch against comBuf.h it compiles keeping your change to
> > osdWireFormat.h.  Sorry for my delay.
> >=20
> > =3D=3D=3D=3D=3D
> > cxx  -c   -pthread -ieee         -DUNIX  -D_OSF_SOURCE   -std gnu  -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=3Dconst char *]" at line 191 of "../comBuf.h"
> >             instantiation of
> >                       "bool comBuf::push(const T &) [with T=3Dconst =
> char *]"
> > at
> >                       line 144 of "../comQueSend.h"
> >             instantiation of
> >                       "void comQueSend::push(const T &) [with =
> T=3Dconst char
> > *]"
> >                       at line 112 of "../comQueSend.cpp"
> >     WireAlias < T > tmp;
> > --------------------^
> > cxx: Error: ../../../include/osiWireFormat.h, line 211: Cannot create
> >           variable "tmp" of incomplete type "WireAlias<<error-type>>".
> >           detected during:
> >             instantiation of "void WireSet(const T &, epicsUInt8 *) =
> [with
> >                       T=3D<error-type>]" at line 213
> >             instantiation of "void WireSet(const T &, epicsUInt8 *) =
> [with
> >                       T=3Dconst char *]" at line 191 of "../comBuf.h"
> >             instantiation of
> >                       "bool comBuf::push(const T &) [with T=3Dconst =
> char *]"
> > at
> >                       line 144 of "../comQueSend.h"
> >             instantiation of
> >                       "void comQueSend::push(const T &) [with =
> T=3Dconst 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: 2 errors detected in the compilation of =
> "../comQueSend.cpp".
> > =3D=3D=3D=3D=3D
> >=20
> > >>> On Thu, 21 Dec 2006 15:34:09 JST,  "Jeff Hill" <[email protected]>
> wrote;
> > > Hello Kazuro,
> > >
> > > Sorry about the delay responding. Part of the reason was a closure =
> of
> > the
> > > lab here yesterday due to some significant snowfall here.
> > >
> > > > > 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.
> > >
> > > The function overload supplied in the comBuf.h patch "bool push ( =
> const
> > char
> > > * value )" satisfies the compiler's quest for a function with the
> > signature
> > > "bool push ( const char value [MAX_STRING_SIZE] )" but isn't 100%
> > correct
> > > because the implementation pushes the value of a pointer into the =
> stream
> > > instead of pushing a string of length MAX_STRING_SIZE into the =
> stream.
> > >
> > > I had a look at why this compiler appears to not be using "template =
> <
> > class
> > > T > bool push ( const T & value )" for T set to epicsOldString. I =
> think
> > I
> > > see the cause in osdWireFormat.h. I committed a fix to CVS. Please =
> try
> > the
> > > latest version from the R3.14 branch in CVS when you get a chance in
> > order
> > > to confirm if my suspicions are correct.
> > >
> > > Many thanks for your assistance with R3.14.9.
> > >
> > > PS: I have attached the patch for your review.
> > >
> > > PPS: I suspect that this matter is related to an issue detected by =
> gcc
> > 4.0
> > > several weeks ago - which apparently wasn't 100% fixed.
> > >
> > > Best Regards,
> > >
> > > Jeff
> > >
> > >
> > > cvs diff -r R3-14-2_branch:yesterday -r R3-14-2_branch -u -wb -i (in
> > > directory
> > > D:\users\hill\epicsMainTrunk\epics\base\src\libCom\osi\os\default\)
> > > cvs diff: Diffing .
> > > Index: osdWireFormat.h
> > > =
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
> > > RCS file:
> > >
> > =
> /net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/default/osdWir=
> e
> > Fo
> > > rmat.h,v
> > > retrieving revision 1.1.2.3
> > > retrieving revision 1.1.2.4
> > > diff -c -u -w -b -i -r1.1.2.3 -r1.1.2.4
> > > cvs diff: conflicting specifications of output style
> > > --- osdWireFormat.h	5 Dec 2006 01:22:04 -0000	1.1.2.3
> > > +++ osdWireFormat.h	21 Dec 2006 22:13:12 -0000	1.1.2.4
> > > @@ -118,10 +118,11 @@
> > >      dst =3D tmp._f;
> > >  }
> > >
> > > -inline void WireGet (
> > > +template <>
> > > +inline void WireGet < epicsOldString > (
> > >      const epicsUInt8 * pWireSrc, epicsOldString & dst )
> > >  {
> > > -    memcpy ( & dst, pWireSrc, sizeof ( dst ) );
> > > +    memcpy ( dst, pWireSrc, sizeof ( dst ) );
> > >  }
> > >
> > >  template <>
> > > @@ -147,10 +148,11 @@
> > >  #   endif
> > >  }
> > >
> > > -inline void WireSet (
> > > +template <>
> > > +inline void WireSet < const epicsOldString > (
> > >      const epicsOldString & src, epicsUInt8 * pWireDst )
> > >  {
> > > -    memcpy ( pWireDst, & src, sizeof ( src ) );
> > > +    memcpy ( pWireDst, src, sizeof ( src ) );
> > >  }
> > >
> > >  template <>
> > >
> > > ***** CVS exited normally with code 1 *****
> > >
> > >
> > >
> > > > -----Original Message-----
> > > > From: [email protected] [mailto:[email protected]]
> > > > Sent: Wednesday, December 20, 2006 3:54 PM
> > > > To: Andrew Johnson
> > > > Cc: Kazuro FURUKAWA; [email protected]; EPICS core-talk; Jeff
> > Hill
> > > > Subject: Re: EPICS on Tru64unix and HP-UX
> > > >
> > > > 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.
> > > > > >
> > > > > > =3D=3D=3D=3D=3D
> > > > > > 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=3Dconst char *]" at line 191 of
> > "../comBuf.h"
> > > > > >             instantiation of
> > > > > >                       "bool comBuf::push(const T &) [with =
> T=3Dconst
> > char
> > > > *]" at
> > > > > >                       line 144 of "../comQueSend.h"
> > > > > >             instantiation of
> > > > > >                       "void comQueSend::push(const T &) [with
> > T=3Dconst
> > > > 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".
> > > > > > =3D=3D=3D=3D=3D
> > > > > >
> > > > > > 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.
> > > > > > =3D=3D=3D=3D=3D
> > > > > > not ok  1 - epicsSnprintf(size=3D1) =3D 0
> > > > > > ok  2 - buffer =3D ''
> > > > > > ok  3 - length =3D 0
> > > > > > not ok  4 - epicsSnprintf(size=3D2) =3D 1
> > > > > > ok  5 - buffer =3D 'i'
> > > > > > ok  6 - length =3D 1
> > > > > > =3D=3D=3D=3D=3D
> > > > > > 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.
> > > > > > =3D=3D=3D=3D=3D
> > > > > > ./epicsTimerTest
> > > > > > 1..33
> > > > > > # Testing timer accuracy
> > > > > > not ok  1 - percentError < messageThresh
> > > > > > # delay =3D 1.000000 s, error =3D -0.007792 s (0.8 %)
> > > > > > not ok  2 - percentError < messageThresh
> > > > > > # delay =3D 1.100000 s, error =3D -0.007204 s (0.7 %)
> > > > > > not ok  3 - percentError < messageThresh
> > > > > > # delay =3D 1.200000 s, error =3D -0.007592 s (0.6 %)
> > > > > > not ok  4 - percentError < messageThresh
> > > > > > # delay =3D 1.300000 s, error =3D -0.007981 s (0.6 %)
> > > > > > not ok  5 - percentError < messageThresh
> > > > > > # delay =3D 1.400000 s, error =3D -0.007393 s (0.5 %)
> > > > > > not ok  6 - percentError < messageThresh
> > > > > > # delay =3D 1.500000 s, error =3D -0.007781 s (0.5 %)
> > > > > > not ok  7 - percentError < messageThresh
> > > > > > # delay =3D 1.600000 s, error =3D -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 +=3D 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
> > >
> >=20
> > =1B$B$h$m$7$/$*4j$$$7$^$9!#=1B(B
> > -----
> > =1B$B8E@n=1B(B =1B$BOBO/=1B(B,  Kazuro FURUKAWA =
> <[email protected]>
> >  Linac&KEKB,  High Energy Accelerator Research Organization (KEK), =
> Japan
> >  Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321
> 

よろしくお願いします。
-----
古川 和朗,  Kazuro FURUKAWA <[email protected]>
 Linac&KEKB,  High Energy Accelerator Research Organization (KEK), Japan
 Telephone: +81-29-864-5200 x4316,  Facsimile: +81-29-864-0321


References:
RE: EPICS on Tru64unix and HP-UX Jeff Hill

Navigate by Date:
Prev: RE: Status Report Jeff Hill
Next: Re: Status Report Matej Sekoranja
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 Jeff Hill
Next: Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
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 ·