Experimental Physics and Industrial Control System
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.)
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 want me to run any tests, supply me with code or tell me what to do. I'll happily try them
out.
Jeff:
I have confirmed that the alpha does align doubles on 8 byte boundaries. A program called "enquire"
in the gcc source code gives lots of information about the platform it is running on.
Once again, thanks for those who have put time into this.
Paul
-----Original Message-----
From: Marty Kraimer [mailto:[email protected]]
Sent: Saturday, 7 December 2002 2:39 AM
To: Jeff Hill
Cc: TYLER, Paul; 'Andrew Johnson'; 'Janet Anderson';
[email protected]; Ralph Lange; Eric Norum; Marty Kraimer
Subject: Re: RISC_pad in dbr_time_double
I have committed the changes I mentioned in a previous message.
Paul,
I hope you get a chance to test on your alpha machine next week. Note that
Andrew makes nightly copies of the CVS repository. We are planning to start
testing next week in preparation for release R3.14.1.
Eric and Ralph,
I am sorry that I forgot to include you on the previous messages about this
topic. It was about problems when a long is 64 bits. Look at core-talk. Some of
the messages appear there. At least enough that you will see the problem.
All,
Remember that next week we start testing in preparation for 3.14.1. Also Andrew
is planning on using 3.14.1 for the EPICS classes he and Bob Dalesio are giving
the first full week in January. He MUST have a version he can use a couple of
days before we leave for Christmas (Dec 21). Thus lets try really really hard to
have a release ready on Dec 16.
Marty
- Replies:
- Re: RISC_pad in dbr_time_double Marty Kraimer
- Navigate by Date:
- Prev:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<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: RISC_pad in dbr_time_double Marty Kraimer
- Next:
Re: RISC_pad in dbr_time_double Marty Kraimer
- Index:
<2002>
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024