Re: EPICS Base 3.14.12.2-rc1 available for testing

[Dirk Zimoch <dirk.zimoch@psi.ch>]

Hi Jeff

Jeff Hill wrote:
> > I wonder why no other compiler complains? Even though the C++ standard
> > states that the system will generate a destructor for you if you don't,
> > declaring the destructor pure virtual in the base class clearly requests
> > that the user defines one.
>
> If the function is virtual in the base class then of course it must be
> virtual in any derived class - independent of whether the virtual keyword is
> present or not. Of course virtual destructors are special and if there is a
> virtual destructor in the base then there must also be one in the derived,
> but I know of no restriction which prevents the compiler from implicitly
> generating a virtual destructor. Nevertheless, if it causes issues we will
> attend to it.

The point is that it is *pure* virtual (i.e. unimplemented): ... = 0;
This makes the base class abstract and no instance can be made. Derived 
classes stay abstract unless all pure virtual functions are defined. 
Here, the destructor is pure virtual and thus must be defined before the 
derived class can be used.

That a virtual function stays virtual in derived classes has little to 
do with this problem. The question is not if the destructor is virtual. 
The problem is that there is no destructor at all.

> > "/usr/include/sys/time.h", line 50: Error: Type name expected instead of
> > "time_t".
>
> I do always try to explicitly import from the standard name space when using
> the "#include <ctime>" form, which is the correct approach for maximizing
> portability, but obviously neglected to do so in this situation.

Your code is correct, the bug is in the ctime or time.h system header. 
But importing the std namespace before including ctime fixes the problem.

Dirk


> Andrew: are you attending to this? If not, I will take care of it. I can
> have a look at the casStreamOS.cc", line 304, issue also.
>
> Jeff
> ______________________________________________________
> Jeffrey O. Hill           Email        johill@lanl.gov
> LANL MS H820              Voice        505 665 1831
> Los Alamos NM 87545 USA   FAX          505 665 5107
>
> Message content: TSPA
>
>
> > -----Original Message-----
> > From: tech-talk-bounces@aps.anl.gov [mailto:tech-talk-bounces@aps.anl.gov]
> > On Behalf Of Dirk Zimoch
> > Sent: Wednesday, November 30, 2011 8:57 AM
> > To: Andrew Johnson
> > Cc: EPICS tech-talk
> > Subject: Re: EPICS Base 3.14.12.2-rc1 available for testing
> >
> > Andrew Johnson wrote:
> > > The first release candidate for the 3.14.12.2 version of Base is now
> > available
> > > on the website for general testing.  Links to the tarfile and Release
> > Notes
> > > can be found at http://www.aps.anl.gov/epics/base/R3-14/12.php
> > >
> > > Please report any problems you find to tech-talk.  If no major issues
> > are
> > > discovered before December 12th we will release 3.14.12.2 on that date.
> > >
> > > Thanks to everyone who has helped with this process.
> > >
> > > - Andrew
> > I tried it on my old sun solaris. It failed with:
> >
> >
> > /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> > -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -D__EXTENSIONS__
> >    -O   +w             -I. -I../O.Common -I. -I..
> > -I../../../include/os/solaris -I../../../include        ../casw.cpp
> > "../udpiiu.h", line 158: Error: Cannot declare a member of the abstract
> > type udpiiu::M_repeaterTimerNotify.
> > "../casw.cpp", line 306: Warning: statement is unreachable.
> > 1 Error(s) and 1 Warning(s) detected.
> > make[3]: *** [casw.o] Error 1
> > make[3]: Leaving directory
> > `/afs/psi.ch/group/8431/dirk/solaris/base-3.14.12.2-rc1/src/ca/O.solaris-
> > sparc'
> > make[2]: *** [install.solaris-sparc] Error 2
> >
> > The reason is that the base class repeaterTimerNotify has a pure virtual
> > destructor  (virtual ~repeaterTimerNotify () = 0;) which is not
> > overwritten by udpiiu::M_repeaterTimerNotify. Thus
> > udpiiu::M_repeaterTimerNotify is still abstract and cannot be
> > instantiated.
> >
> > Add: ~M_repeaterTimerNotify () {};
> >
> > I wonder why no other compiler complains? Even though the C++ standard
> > states that the system will generate a destructor for you if you don't,
> > declaring the destructor pure virtual in the base class clearly requests
> > that the user defines one.
> >
> > After fixing this I get:
> >
> > /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> > -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -D__EXTENSIONS__
> >    -O   +w             -I. -I../O.Common -I. -I..
> > -I../../../../include/os/solaris -I../../../../include
> > ../epicsTimeTest.cpp
> > "/usr/include/sys/time.h", line 50: Error: Type name expected instead of
> > "time_t".
> > 1 Error(s) detected.
> > make[3]: *** [epicsTimeTest.o] Error 1
> >
> > The problem is a bug in the way the solaris compiler handles the
> > standard C header file time.h when included from C++ via ctime. It hides
> > the typedef long time_t; into namespace std and later in the same header
> > file fails to find it.
> >
> > To fix this, I had to move
> > using namespace std;
> > in front of
> > #include <ctime>
> >
> >
> > Next problem:
> > /afs/psi.ch/sys/@sys/sepp/bin/CC -c  -D_POSIX_C_SOURCE=199506L
> > -D_XOPEN_SOURCE=500            -DUNIX  -DSOLARIS=8 -mt  -D__EXTENSIONS__
> >    -O   +w           -xcode=pic32  -I. -I../O.Common -I. -I..
> > -I../../../../src/cas/generic -I../../../../src/cas/io/bsdSocket
> > -I../../../../src/cas/generic/st -I../../../../src/cas/../ca
> > -I../../../../include/os/solaris -I../../../../include
> > ../../../../src/cas/generic/st/casStreamOS.cc
> > "../../../../src/cas/generic/st/casStreamOS.cc", line 304: Error:
> > "casStreamOS::armRecv()" has already been called and cannot be defined
> > inline.
> > 1 Error(s) detected.
> > make[4]: *** [casStreamOS.o] Error 1
> >
> > Damn, why is this an error instead of a warning? Anyway:
> > Put inline void casStreamOS::armRecv() before casStreamIOWakeup::expire().
> >
> >
> >
> > cap5 does not work at all because my perl version has been compiled with
> > a different compiler and all the compiler options don't work. The reason
> > was that I needed a newer perl version to compile EPICS than the one
> > that was already installed. It seems the guy who compiled perl 5.8.8
> > used gcc instead of the system compiler.
> >
> > Maybe the cap5/Makefile should check for compatibility between the
> > current compiler and the options returned from perlConfig.pl
> > (perlConfig.pl cc) or change not only CFLAGS but CC too.
> >
> >
> > Otherwise all is fine :-)
> >
> > I successfully compiled for
> > vxWorks 5.5 ppc604 (aka Tornado 2.2)
> > vxWorks 6.3 ppc603 (used on cRIO)
> > vxWorks 6.7 ppc604
> > linux xscale_be (Montavista gcc version 3.4.3)
> > linux ppc405 (embedded in Virtex 5, Crosstool gcc version 4.0.2)
> > Scientific Linux 5.1 x86
> > Scientific Linux 6.0 x86_64
> > Scientific Linux 6.0 x86 (cross build on 64 bit machine)
> >
> >
> > For your info:
> >  > perl -v
> > This is perl, v5.8.8 built for sun4-solaris
> >  > perl perlConfig.pl cc
> > gcc
> >  > /afs/psi.ch/sys/@sys/sepp/bin/cc -V
> > cc: Sun WorkShop 6 update 2 C 5.3 2001/05/15
> >  > uname -a
> > SunOS pssvxw.psi.ch 5.8 Generic_108528-19 sun4u sparc SUNW,Sun-Blade-100
> >
> >
> > Dirk