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
<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 Andrew Johnson
- Next:
RE: EPICS on Tru64unix and HP-UX 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
|