I guess I forgot to stress the phrase "a lot". Not long ago I decided
to change from using symbolic links out of the standard locations
(/usr/local/lib. /usr/local/bin. etc.) to installing the files directly
into those locations. I "only" had to change the makefiles and run
"make install". With all the inevitable gotchas, it took quite a while.
I don't know what problems Lincoln ran into. That was quite a while ago
and I declined to get involved.
The last time I heard anything from TAMS about 64-bit support, they
suggested reverting to 32-bit mode or getting a dedicated 32-bit
instrument controller. Lately, they haven't responded to e-mails.
I'm just saying, think about it before you decide to switch over.
Out of curiosity, if NRAO has selected RH, why do you still use Debian?
There must be some case for running both distributions side-by-side,
though I'd prefer not to.
Cheers
Tom
Scott Ransom wrote:
On Wednesday 10 February 2010 09:00:59 am Tom Kuiper wrote:
For reasons that are implicit in this finding, I suggest that if you
have a lot of locally developed software running under a Debian-like
distribution, that you buy a new computer dedicated to the Xilinx
toolflow (and any other RH-only supported software). Converting all
your existing code from Debian to RH will prove very labor intensive.
Huh? I'm sorry, but if you have even halfway portable code that is
absolutely not the case. My primary development platform is Debian, but
_many_ of the systems that I run on are RHEL5 based (NRAO runs RHEL5).
As long as any Linux system is modern, there should be _no_ porting
issues.
One thing that _is_ tricky is the GNU transition from g77 to gfortran as
the ABI has changed several times. But I don't suspect many people on
this list are using Fortran for their development.
And another tricky thing potentially is 32-bit to 64-bit. But that has
nothing to do with Debian to RHEL either.
Bottom line: if you write good ANSI C, all you'll have to do is re-make
on RHEL.
Scott
