As far as i understand the intel small print,
you are allowed to distribute binaries compiled with intel compilers,
along with s a few intel libraries that are required by the libraries
you compile.
But not sell them i think.
Dan
On 16 Feb 2007, at 01:34, 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
>>
>>
>
>
> --
> Lynn F. Ten Eyck [log in to unmask]
> San Diego Supercomputer Center (858) 534-5141 (Voice)
> University of California, San Diego (858) 822-3610 (Fax)
> 9500 Gilman Drive #0444 Office: 3131 Atkinson Hall
> La Jolla, CA 92093-0444
Dr. Daniel James White BSc. (Hons.) PhD
Bioimaging Coordinator
Nanoscience Centre and Department of Biological and Environmental
Sciences
Division of Molecular Recognition
Ambiotica C242
PO Box 35
University of Jyväskylä
Jyväskylä
FIN 40014
Finland
+358 14 260 4183 (work)
+358 468102840 (mobile)
http://www.bioimagexd.net
http://www.chalkie.org.uk
[log in to unmask]
[log in to unmask]
