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
<2006>
2007
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
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|