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, "[log in to unmask]" <[log in to unmask]> 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: [log in to unmask]
>>To: [log in to unmask]
>>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" <[log in to unmask]
>><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
|