Re: RISC_pad in dbr_time_double

[Marty Kraimer <mrk@aps.anl.gov>]

All,

I committed changes to dbStaticRun.c The changes check for int_MAX in 
realToString and also use  epicsInt32 and epicsUint32 for values transfered 
to/from long fields in records.


TYLER, Paul wrote:
> Hi Marty & Jeff (and everyone else),
>
> I have compiled R3.14.0 cvs release of 8th Dec 2002 on our alphastations, using gcc3.2 under Digital
> Unix 4.0d.  Initial tests (all I'm capable of doing at the moment) indicate that it works just as my
> patched R3.14.0beta2 version did.  So thanks for the work.  (And I heard a couple of days ago that
> HP are discontinuing development of the alpha chip!  I suppose there will be new 64 bit machines
> come along though.)

Just an aside. It appears that on solaris long is 32 bits unless a compiler flag 
is specified. I tried it but then I was not compatible with the libraries. It 
appears that on solaris the way to get 64 bit integers is via "long long".


> The steps I required to compile the CVS version were:
> 1) Install my configuration files.  I've used "alpha-osf-gnu" for the architecture
> (EPICS_HOST_ARCH).
> 2) In src/libCom/osi/os, I made a directory "osf" and copied the contents of "alpha".  I'm not sure
> what "alpha" is for but the scripts/Makefiles go looking for an "osf" directory.  I also added the
> SD_BOTH definition to osdSock.h in the osf directory.  It use to be in that file in the "alpha"
> directory for the beta2 release, but has gone in the cvs release.  I didn't look into what that did.
> I just put it back and hoped for the best!


> 3) There are issues with osdMutex.c.  The test on _XOPEN_SOURCE and the default osf/digital Unix
> settings in /usr/include/standards.h cause an error.  Under osf _XOPEN_SOURCE is defined but has no
> value and for some reason, this caused cpp to give an error.  That doesn't happen under x86 linux.
> I can't work it out.  Anyway, I inserted various -D options in the configuration files to use the
> code for _XOPEN_SOURCE<=500.  I didn't assess whether the new code would work.
>
> If someone wants a tar of the files I needed to add, I'm happy to supply it.

If you have files to put in <base>/configure/os/ then I please prepare justb 
these files and send them to Janet. remember, however, that we have no way to 
test alpha here at APS.


> If you want me to run any tests, supply me with code or tell me what to do.  I'll happily try them
> out.


Again we are hoping to anounce 3.14.1 next Monday. Thus we still have this week 
for testing.

Marty