Experimental Physics and Industrial Control System
Hello Andrew,
Thank you for the releases of EPICS base. I've installed R3.14.9
during the weekend. And I've put another Tru64unix patch which was
not incorporated into the release.
<URL:http://www-linac.kek.jp/jk/osf/base-3.14.9-osf-alpha.patch>
I don't know how to treat it. If it is possible, please consider
it again in some way. I'm sorry that I'm slow at creating it.
Above patch is not clean yet, since I don't yet understand the
behavior of the link editor. For example, libCom and librecIoc
are dependent on libm, so I thought every executable which use
libCom or librecIoc needs libm or -lm on the linking command.
Actually the link editor on tru64unix requires this even though
it is not a static build. However, current configure scripts for
linux and others does not specify them. Even epicsMathTest does
not have -lm on the linking stage, while tru64unix requires it.
Above behavior is defined in CONFIG.Common.UnixCommon currently.
Does every unix flavor other than tru64unix follow the same concept?
If so, I'll consider to create a configure script for tru64unix
which is not dependent on CONFIG.Common.UnixCommon.
Also the patch for comBuf.h is still dirty. Please let me know
if you have any idea to try.
Cheers.
>>> On Sat, 23 Dec 2006 10:39:05 JST, Kazuro FURUKAWA <[email protected]> wrote;
> Hello Andrew,
>
> I've put interim patch
> <http://www-linac.kek.jp/jk/osf/base-3.14.9-cvs-dec22-osf-alpha.patch>
> which is against
> <http://www.aps.anl.gov/epics/download/base/base_R3-14_cvs.tar.gz>
> dated dec.22 06:07 GMT.
>
> The patch contains my dirty patch for comBuf.h, which may be
> eliminated by Jeff's next patch. Also, I didn't understand where
> I should put "-lm" for catime and epicsCalcTest, etc. Thus, I
> used USR_SYS_LIBS for now, although I understand you don't like
> this. I don't understand what is LDLIBS for.
> The error of epicsVsnprintf was eliminated with a dirty modification
> to epicsStdio.c.
>
> The compilation log with native cc/cxx is
> <http://www-linac.kek.jp/jk/osf/base-3.14.9cvs-make-osf.log>
> and the test result is
> <http://www-linac.kek.jp/jk/osf/base-3.14.9cvs-test-osf.log>
> which still shows timer errors... Gcc errors are
> <http://www-linac.kek.jp/jk/osf/base-3.14.9cvs-make-osf-gnu.log>
> which shows osiWireFormat.h error.
>
> >>> On Thu, 21 Dec 2006 10:19:56 JST, Kazuro FURUKAWA <[email protected]> wrote;
> > >>> On Wed, 20 Dec 2006 17:40:09 JST, Andrew Johnson <[email protected]> wrote;
> > >
> > > Kazuro FURUKAWA wrote:
> > > >
> > > >>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.
> > >
> > > Actually there are several different standards which conflict with each
> > > other, hence the multitude of behaviours we see. The C99 standard is
> > > merely the latest and arguably the most useful, which is why we're
> > > trying to emulate that in the epicsSnprintf() call.
> >
> > I didn't know those conflicting standards.
> >
> > > > I'm thinking about a dirty wrapper around their vsnprintf(), if I
> > > > have time.
> > >
> > > The simplest approach is to copy the src/libCom/osi/os/posix/osdStdio.c
> > > file into the osi/os/osf directory and make whatever changes you need to
> > > the behaviour there. That file will then be used instead of the posix
> > > version on OSF.
> >
> > I thought about your suggestion. I may try to call vsnprintf() and
> > then try with larger buffer only if the output is truncated.
> >
> > > > [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.
> > >
> > > I'm afraid I don't completely follow the exact changes you described
> > > above; it's probably safest and quickest if you email us the differences
> > > between the CVS snapshot and the files you need.
> >
> > Sorry my description was bad, because I didn't understand CONFIG
> > files well. The simplest modification is to add
> > USR_SYS_LIBS += m
> > in CONFIG.Common.osf-alpha since -lm in OP_SYS_LDLIBS is overwritten
> > by some mechanism. However, I suppose it is better to leave USE_*
> > for users' Makefiles. I should make better files.
-----
Kazuro FURUKAWA <[email protected]>
Linac&KEKB, High Energy Accelerator Research Organization (KEK), Japan
Telephone: +81-29-864-5200 x4316, Facsimile: +81-29-864-0321
- Navigate by Date:
- Prev:
Re: necessary changes in caServer code for redundancy support Jeffrey O. Hill
- Next:
Patch for 3.14.9 Benjamin Franksen
- 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: necessary changes in caServer code for redundancy support Jeffrey O. Hill
- Next:
Patch for 3.14.9 Benjamin Franksen
- Index:
2002
2003
2004
2005
2006
<2007>
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024