> 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
<2011>
2012
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
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|