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
>
> Hello Jeff,
>
> 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.
>
> =====
> 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=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: 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=<error-type>]" at line 213
> 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: 2 errors detected in the compilation of "../comQueSend.cpp".
> =====
>
> >>> 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
> > ===================================================================
> > RCS file:
> >
> /net/phoebus/epicsmgr/cvsroot/epics/base/src/libCom/osi/os/default/osdWire
> 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 = 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.
> > > > >
> > > > > =====
> > > > > 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
> >
>
> よろしくお願いします。
> -----
> 古川 和朗, 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 Kazuro FURUKAWA
- Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- References:
- Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Navigate by Date:
- Prev:
Re: EPICS on Tru64unix and HP-UX Kazuro FURUKAWA
- Next:
RE: Status Report Jeff Hill
- 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 Kazuro FURUKAWA
- 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
|
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·