I am using the Intel ifort for the precompiled versions of shelx that I
distribute for Linux, Windows and IntelMac. I am pretty happy with it
and it produces very fast code. However I am only producing 32-bit
binaries and for reasons indicated by Lynn I bought commercial licences
(and also pay for the software support, though the main use of the
support is to continue to get updates). The only real advantage I can
see of using 64-bit code would be to use larger matrices for full-matrix
least-squares refinement in shelxl (to get real esds), the 32 bit code
seems to run fine on 64-bit systems.
George
Lynn Ten Eyck wrote:
I have used the Intel compilers, and yes, they work pretty well. However,
they do not solve this particular problem. I have one problem with them; if
you read the fine print on the academic license, you find that you are not
supposed to use them for things other than your own research unless you pay
for them. Since I try to write software for wide free distribution, whether
or not this counts as my own research is a gray area.
Lynn Ten Eyck
On 2/15/07 9:45 PM, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
Although I have not yet tried to compile coot or CCP4, I have found that the
GNU provided packages (gcc, g77) do not make life convenient (how is that for
a euphamism for 'banging your head against the wall)?
Things worked better with gfortran than g77 and again better with the Intel
compilers (both fortran and C(++)). When I say 'worked better' this means
'less effort to get it working' and also (particularly in case of Intel)
'faster'. My experience was not with Fedora but with RHEL (similar problems as
described below, not the same though).
In my humble opinion it is worth to spend the money, get the paid-for
compiler, and get around the problems like the one you describe. Life gets
even better: if you want to try, you can get a free trial license for either
fortran or C(++) or both and convince yourself that it is better. The Intel
compilers are a one-time expense with an indefinite license, but you must pay
annually if you want support. Academic licenses are (appropriately)
inexpensive.
My 2 cents worth.
Mark
-----Original Message-----
From: [EMAIL PROTECTED]
To: [email protected]
Sent: Wed, 14 Feb 2007 1:09 PM
Subject: Re: [ccp4bb] x86-64
Dear Phil,
Good luck . . . I have been fighting an x86_64 system for some time, and
have just figured out what some of the problems are. I am running Fedora
Core 5.
I believe that if you use the -m32 flag for gcc you can compile 32-bit code
for 32-bit libraries. The default is to compile 64-bit and link 64-bit.
The real joker in the deck is the file system layout:
/usr Default root prefix
/usr/include Used for both 32 and 64 bit systems
/usr/lib Libraries for 32-bit code
/usr/lib64 Libraries for 64-bit code
/usr/bin For both -- the operating environment is encoded in the file
This breaks the standard prefix scheme for prefix/{include,lib,src,...}
because it is not easy to tell when you need lib and when you need lib64.
I was unable to compile Coot from source until the last day or so because
the linker kept putting the 32-bit libGL.so in the search path. This is a
fatal error.
I finally tracked this to a bug in libtool, which figures out about the
32/64 bit issues *nearly* all of the time. Sigh.
Short answer: get the latest, bleeding-edge Autoconf package from the GNU
web site and install it. It is alpha, but seems to work, and the configure
scripts once generated can be run almost anywhere. (Oh, you may also have
to upgrade M4.)
*Note* I got Autoconf 2.61, but the real key seems to be the version number
on the libtool macros. Version 1.2248 does not work, but Version 1.2381
does work on my system. Unfortunately the latest versions are also more
picky about the macros, so if autoupdate can't fix them, you have to do some
hand editing.
I will be happy to follow up on this off-line, and expect to post a summary
on the Coot bulletin board once I have some loose ends tidied up. I suspect
this may be why I have had problems trying to build ccp4mg from source on
this machine, as well.
Overall the machine runs really well, but you do hit the occasional package
that is not 64-bit clean.
Best regards,
Lynn Ten Eyck
On 2/14/07 10:00 AM, "Phil Evans" <[EMAIL PROTECTED]
<javascript:parent.ComposeTo("pre%40MRC-LMB.CAM.AC.UK", "");> > wrote:
I'm just starting to use a 64-bit Linux machine (running some sort of
RedHat Enterprise system) as a development machine
Our general CCP4 installation is from the binary download (redHat
option) (presumably built on a 32-bit machine), which seems to run OK
on a range of different Linux machines
However if I compile on the 64-bit machine & try to link with these
libraries, it doesn't work
r/bin/ld: skipping incompatible /public/xtal/ccp4-6.0/ccp4-6.0.2-
linux/lib/libccp4f.a when searching for -lccp4f
/usr/bin/ld: cannot find -lccp4f
collect2: ld returned 1 exit status
make: *** [scala] Error 1
Is it possible to set compile flags to produce something (.o) which
will link with th distributed libraries, and produce an executable
which will run on other (32-bit) Linux machines?
In the mean time, I'm doing a complete source build on the 64-bit
machine
Phil
--
Prof. George M. Sheldrick FRS
Dept. Structural Chemistry,
University of Goettingen,
Tammannstr. 4,
D37077 Goettingen, Germany
Tel. +49-551-39-3021 or -3068
Fax. +49-551-39-2582
