NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
NOTICE: This version of the NSF Unidata web site (archive.unidata.ucar.edu) is no longer being updated.
Current content can be found at unidata.ucar.edu.
To learn about what's going on, see About the Archive Site.
On Monday 09 February 2009, Peter Laws wrote: > Dan Vietor wrote: > > I'm just now starting to do work in 64 bit space. I've found that > > most programs that are compiled for 32 bits will run without > > modification on 64 bit systems. The problem I've found is that > > there are some issues with backward compatibility of some of the > > older shared libraries. For example, WXP compiled for 32 bit > > RHEL3 would not run on 64 bit RHEL5 because of missing 32 bit > > shared libraries. The 32 bit compile for RHEL5 worked without a > > problem. I'm researching this backward > > That sounds like Sun days of yore (SPARC went 64-bit nearly 15 years > ago). Remember when the 64-bit version of stuff wasn't always there > (SUNW....x in the pkg name)? Yes, it's unfortunate that RH decided to do it the "stupid" way, which keeps the system from being 99% backwards compatible with 32-bit programs; who really needs a 64-bit address space version of 'ls' anyways? This is one of my reasons that I prefer Debian - all the basic system libraries are compiled for both 32 and 64 bit, and the number of 64-bit libraries keep expanding... at least with Linux/OSS you can compile the needed 64-bit libraries yourself, unlike the proprietary bits in UNIX. Now if just everyone else would follow suit, and switch to doing things the more sane way, I'd be just a little bit happier. :) Pat -- Purdue University Research Computing -- http://www.itap.purdue.edu/rcac
ldm-users archives: