Experimental Physics and
Industrial Control System

"Jeff Hill" <[email protected]> · Mon, 4 Dec 2006 18:27:04 -0700

Eric,

I comitted a revised version of osiWireFormat.h and osdWireFormat.h that
hopefully will work around what appears to be a gcc 4.1.1 specific issue.

Does anyone know what the ramifications of installing gcc 4 (the host
targeting version) into a Linux system that is built with gcc 3.x? I am
unable to obtain gcc 4.0 for cygwin or mingw. 

Jeff

> -----Original Message-----
> From: Eric Norum [mailto:[email protected]]
> Sent: Monday, December 04, 2006 12:34 PM
> To: Jeff Hill
> Cc: 'Core talk list'
> Subject: Re: osiWireFormat.h problems
> 
> 
> On Dec 4, 2006, at 12:52 PM, Jeff Hill wrote:
> 
> >
> > Eric,
> >
> > It would easier from my end if I could see the compiler errors before
> > changes were made.
> 
> Those were in my original message:
> ====================================================================
> I did a CVS update this morning and can no longer build base:
> 
> /usr/local/rtems/rtems-4.7/bin/m68k-rtems4.7-g++ -B/usr/local/rtems/
> rtems-4.7/m68k-rtems4.7/uC5282/lib/ -specs bsp_specs -qrtems   -c   -
> m528x               -DUNIX    -ansi  -O4 -g -g  -Wall      -
> DMY_DO_BOOTP=NULL    -
> DRTEMS_NETWORK_CONFIG_DNS_DOMAINNAME=aps.anl.gov -
> DRTEMS_NETWORK_CONFIG_DNS_DOMAINNAME=aps.anl.gov  -I. -I.. -I../../../
> include/os/RTEMS -I../../../include         ../casw.cpp
> ../../../include/osiWireFormat.h: In function 'void AlignedWireGet
> (const T&, T&) [with T = short unsigned int]':
> ../../../include/osiWireFormat.h:109:   instantiated from
> 'AlignedWireRef<const T>::operator T() const [with T = short unsigned
> int]'
> ../casw.cpp:154:   instantiated from here
> ../../../include/osiWireFormat.h:230: error: 'tmp' has incomplete type
> ../../../include/osiWireFormat.h:230: error: storage size of 'tmp'
> isn't known
> make[3]: *** [casw.o] Error 1
> make[2]: *** [install.RTEMS-uC5282] Error 2
> make[1]: *** [ca.install] Error 2
> make: *** [src.install] Error 2
> 
> 
> 
> norume@gnarly 224> /usr/local/rtems/rtems-4.7/bin/m68k-rtems4.7-g++ --
> version
> m68k-rtems4.7-g++ (GCC) 4.1.1
> Copyright (C) 2006 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> ====================================================================
> 
> >
> > Are you providing a new RTEMS specific osdWireFormat.h instead of
> > just using
> > the one found in osi/os/default?
> 
> I'm just using the one in osi/os/default.
> 
> > It is also possible that you are seeing a
> > warning that the osdWireFormat.h header file couldn't be found?
> 
> No.  The above is the entire output error message.
> 
> 
> > That might
> > be because the RTEMS specific gnu make "vpath" configuration for
> > the libCom
> > build does not allow osdWireFormat.h to be installed from the osi/
> > os/default
> > directory? It seems that that one of the above circumstances would be
> > necessary for you to see these errors.
> >
> > Another possibility might be that your woes are specific to GCC 4.0
> > which is
> > difficult to test as they have not installed it on any Linux system
> > here and
> > you can't get gcc 4.0 at this time for cygwin. It doesn't seem to be
> > particularly likely that there would be problems with gcc 4.0 however
> > because the code involved looks quite standard and has compiled on
> > many
> > compilers.
> 
> My OS X machines use gcc 4.0.1:
> norume@ctlstrmvid0 18> g++ --version
> powerpc-apple-darwin8-g++-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc.
> build 5363)
> Copyright (C) 2005 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There
> is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
> PURPOSE.
> 
> The RTEMS compiler is gcc-4.1.1 (as shown in my original message).
> 
> >
> > The gory details go like this. The WireAlias template is only
> > needed for the
> > primitive types where the byte swap can be done as an alias of an
> > unsigned
> > type {epicsInt8, epicsInt16, epicsInt32, epicsFloat32}. Closer
> > inspection
> > reveals that the WireAlias template is used only by the following
> > template
> > functions which assume that the byte swap can be done as an
> > unsigned alias.
> > Where that default assumption does not work, explicit versions of
> > these
> > template functions (ordinary functions with the same callable
> > interface as
> > the template functions) are provided in osdWireFormat.h for the
> > appropriate
> > types where there might be architecture specific issues {epicsUInt16,
> > epicsUInt32, epicsFloat64, epicsOldString}. Because the explicit
> > versions of
> > these functions do not use the WireAlias template then the explicitly
> > implemented types need not be supplied for the WireAlias template.
> >
> > template < class T >
> > inline void WireGet ( const epicsUInt8 * pWireSrc, T & dst );
> >
> > template < class T >
> > inline void WireSet ( const T & src, epicsUInt8 * pWireDst )
> >
> > template < class T >
> > inline void AlignedWireGet ( const T & src, T & dst );
> >
> > template < class T >
> > inline void AlignedWireSet ( const T & src, T & dst );
> >
> > Furthermore, note that if the explicit function definitions are
> > properly
> > provided in osdWireFormat.h then it does not hurt to define the
> > additional
> > WireAlias types, but this shouldn't be done because it certainly
> > adds unused
> > source code and it also makes catching explicit function
> > definitions missing
> > from an OS specific osdWireFormat.h less likely at compile time.
> >
> > I will give you a call later today.
> >
> 
> --
> Eric Norum <[email protected]>
> Advanced Photon Source
> Argonne National Laboratory
> (630) 252-4793

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System