EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: EPICS Base 3.14.12.2-rc1 available for testing
From: "Jeff Hill" <[email protected]>
To: "'Dirk Zimoch'" <[email protected]>, "'Andrew Johnson'" <[email protected]>
Cc: "'EPICS tech-talk'" <[email protected]>
Date: Thu, 1 Dec 2011 09:43:40 -0700
> 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.

> "/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.

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        [email protected]
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> 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



Replies:
Re: EPICS Base 3.14.12.2-rc1 available for testing Dirk Zimoch
References:
EPICS Base 3.14.12.2-rc1 available for testing Andrew Johnson
Re: EPICS Base 3.14.12.2-rc1 available for testing Dirk Zimoch

Navigate by Date:
Prev: Re: finite() Till Straumann
Next: RE: Asyn: "devAsynInt32::initCommon Link must be INST_IO" Piccoli, Luciano
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: EPICS Base 3.14.12.2-rc1 available for testing Dirk Zimoch
Next: Re: EPICS Base 3.14.12.2-rc1 available for testing Dirk Zimoch
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  2006  2007  2008  2009  2010  <20112012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 18 Nov 2013 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·