Experimental Physics and
Industrial Control System

Kazuro FURUKAWA <[email protected]> · Thu, 15 Feb 2007 04:13:20 +0900

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System