Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Thu, 2 Oct 2008 09:52:34 -0600

Kazuro San,

Many thanks for your patches. It always helps to compile a code on multiple
compilers, and the __DECCXX compiler was no exception in this situation. I
committed a small revision to your CA patch as follows this morning.

I created Mantis entry 322 to document the issue.

Thanks again for your kind assistance,

Jeff

cvs diff -wb (in directory C:\...\epics\base\src\ca\)
? Edit1.TXT
? RCa01512
? tst.cpp
Index: comBuf.h
===================================================================
RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/ca/comBuf.h,v
retrieving revision 1.29.2.6
diff -u -b -w -b -r1.29.2.6 comBuf.h

--- comBuf.h	28 Jul 2008 16:19:49 -0000	1.29.2.6
+++ comBuf.h	2 Oct 2008 15:31:52 -0000
@@ -116,6 +116,8 @@
     epicsUInt8 buf [ comBufSize ];
     void * operator new ( size_t size );
     void operator delete ( void * );
+    template < class T >
+    bool push ( const T * ); // disabled
 };
 
 inline void * comBuf::operator new ( size_t size, 
Index: comQueSend.cpp
===================================================================
RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/ca/comQueSend.cpp,v
retrieving revision 1.36.2.3
diff -u -b -w -b -r1.36.2.3 comQueSend.cpp
--- comQueSend.cpp	4 Nov 2005 14:37:02 -0000	1.36.2.3
+++ comQueSend.cpp	2 Oct 2008 15:21:06 -0000
@@ -106,10 +106,7 @@
 
 void comQueSend::copy_dbr_string ( const void * pValue )
 {
-    // this extra step is required by Borland BCC 5.5
-    const dbr_string_t & str = 
-        * static_cast <const dbr_string_t *> ( pValue );
-    this->push ( str );
+    this->push ( static_cast < const char * > ( pValue ), MAX_STRING_SIZE
);
 }
 
 void comQueSend::copy_dbr_short ( const void * pValue )
@@ -186,7 +183,7 @@
 
 void comQueSend::copy_dbr_string ( const void *pValue, unsigned nElem ) 
 {
-    this->push ( static_cast <const dbr_string_t *> ( pValue ), nElem );
+    this->push ( static_cast < const char * > ( pValue ), nElem *
MAX_STRING_SIZE );
 }
 
 void comQueSend::copy_dbr_short ( const void *pValue, unsigned nElem ) 
Index: comQueSend.h
===================================================================
RCS file: /net/phoebus/epicsmgr/cvsroot/epics/base/src/ca/comQueSend.h,v
retrieving revision 1.21.2.3
diff -u -b -w -b -r1.21.2.3 comQueSend.h
--- comQueSend.h	11 Jan 2007 21:38:59 -0000	1.21.2.3
+++ comQueSend.h	2 Oct 2008 15:04:57 -0000
@@ -149,6 +149,9 @@
         this->pushComBuf ( *pComBuf );
     }
 
+    template < class T >
+    inline void push ( const T * ); // disabled
+
     comQueSend ( const comQueSend & );
     comQueSend & operator = ( const comQueSend & );
 };

***** CVS exited normally with code 1 *****

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> On Behalf Of Kazuro FURUKAWA
> Sent: Thursday, October 02, 2008 7:47 AM
> To: Andrew Johnson
> Cc: EPICS core-talk
> Subject: Re: EPICS Base R3.14.10-pre1 available for testing
> 
> Dear Andrew,
> 
> >>> On Mon, 15 Sep 2008 18:07:25 JST,  Andrew Johnson <[email protected]>
> >>> wrote;
> >
> > Please report both bugs and successes to the tech-talk list, including
> > the
> > architecture(s) you're using and the versions of any other tools if
> relevent.
> 
> Thanks for your preparation, and sorry for my slow response.
> 
> I tried less popular architectures, osf-alpha, darwin, that we use, as
well
> as linux.
> 
> As usual, osf-alpha needs the attached patch, that is almost the same as
> that against 3.14.9.  I know it is dirty, but I don't know any other
> solution.  And the resultant build and runtest logs are placed at
>   <URL:http://www-linac.kek.jp/epics/osf/>
> 
> Darwin-x86 showed error in the linkage stage of libCom shared lib,
>   /usr/bin/c++ -o libCom.3.14.10pre1.dylib -dynamiclib ...
> Error messages are
> On Tiger (8.11.1):
>   /usr/bin/libtool: third field (10pre1) in argument for:
>   -current_version 3.14.10pre1 not a proper unsigned number On Panther
> (9.4.1):
>   ld: malformed version number: 3.14.10pre1
> 
> I know this is a minor problem.  But, it seems the shared library name on
> osf-alpha and linux-x86_64 are "libCom.so.3.14", that does not lead to any
> error.  Can we use the same naming scheme?
> 
> Regards.
> -----
> 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