-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Robert Schiele wrote:
> On Tue, Nov 08, 2005 at 10:59:22AM +0100, Pascal Bleser wrote:
>> Using icc will result in having to install icc runtime libraries, at least
>> for C++.
>> (see libstdc++ and libgcc for g++)
>
> Wrong. On a Linux system icc uses by default the gcc provided libstdc++ if
> installed and the other support libraries can be linked in statically by the
> -i-static switch.
Ok, nice. So -i-static *must* be passed. Correct ?
If not, are there packages of the "other" (non-libstdc++) icc runtime libraries
?
(that would have to be shipped as part of SUPER)
>> What licenses apply to the runtime libraries ?
> "C. Subject to all of the terms and conditions of this Agreement, Intel
> grants to you a non-exclusive, non-assignable copyright license to
> distribute (except under an Evaluation License as specified below) the
> Redistributables, or any portions thereof, as part of the product or
> application you developed using the Materials."
> Note that all libraries that icc links to by default are "Redistributables".
Ok, that's covered as well.
>> On what architectures are they available ?
> i586, x86_64, and ia64.
Ok.
>> How well is RPM currently handling building with icc ? (flags, archs, ...)
> Huh? RPM does not really care about the compiler you use.
/usr/lib/rpm/macros:%__cxx g++
My point is: if people plan to build RPMs with icc, there must be a common
policy on how to tell RPM
to use icc instead of g++
IMO it must be external to the spec file (i.e. not write "%define __cxx icc" in
the spec file),
which may sound obvious, but when I saw Damian writing "BuildArch: i686" there
doesn't necessarely
seems to be a correct understanding of how RPM is supposed to be used.
The spec files should fall back nicely to g++.
Also, the %optflags defined for rpmbuild (in /usr/lib/rpm/rpmrc and
/usr/lib/rpm/*-linux/macros) are
tailored for GCC, not for icc, e.g.:
optflags: i686 -O2 -g -march=i686 -mtune=i686 -fmessage-length=0
-D_FORTIFY_SOURCE=2
- -O and -g should be fine with icc (I assume), but -fmessage-length and -mtune
most definately not
(unless icc provides a g++ front).
Would most probably mean adding the following line in ~/.rpmmacros:
%define __cc icc
%define __cxx icc
And adding corresponding options in ~/.rpmrc (see /usr/lib/rpm/rpmrc)
And patching plenty of Makefiles that explicity use "gcc" or "g++", instead of
using a "CC" and
"CXX" make variables you would have to pass as well:
%__make CC="%__cc" CXX="%__cxx" CFLAGS="%{optflags}" CXXFLAGS="%{optflags}"
For projects that use autoconf, they most probably will use "gcc"/"g++" by
default, so you must pass
some stuff to ./configure - probably like this:
CC="%__cc" CXX="%__cxx" CFLAGS="%{optflags}" CXXFLAGS="%{optflags}" \
./configure \
...
Even if you use the %configure macro in your spec files (which is highly
encouraged), it does *NOT*
pass CC nor CXX to ./configure (see yourself: /usr/lib/rpm/macros), which means
every spec file has
to do the following:
CC="%__cc" CXX="%__cxx" %configure ...
(and do check the rpmbuild output to see whether it actually uses "icc" and not
"gcc"/"g++")
>> Needs quite some investigation upfront, IMO.
> Technically there is no real problem using this compiler. But you should make
see above ;)
> sure yourself whether you comply to this:
> "ii. NONCOMMERCIAL-USE LICENSE: If you are using the Materials under the
> control of a Noncommercial-Use license, you as an individual may use the
> Materials only for non-business use where you receive no fee, salary or
> any other forms of compensation. The Materials may not be used for any
> other purpose, whether "for profit" or "not for profit." Any work
> performed or produced as a result of use of the Materials cannot be
> performed or produced for the benefit of other parties for a fee,
> compensation or any other reimbursement or remuneration."
This is fine for people here who would build RPMs with icc.
But if, say, those RPMs are included into SUPER... what are the implications ?
To me, given the license excerpt above, it would "just" mean that you may not
charge a fee for
SUPER. I'm not sure whether that conflicts with the GPL.
If not, then it's just that everyone using and participating in SUPER
development must be aware of
this. And everyone must agree it's a "non issue".
cheers
- --
-o) Pascal Bleser http://linux01.gwdg.de/~pbleser/
/\\ <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>
_\_v FOSDEM 2006 -- 25+26 February 2006 in Brussels
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDcL5er3NMWliFcXcRAgDYAJ9G5b8A7cEKy+KtYsb47pcPX2F0VQCfW6zt
2knom8KWbYdc7og8QaqusCA=
=O2dI
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
