I believe lang/icc* are not open-source nor 'free', right?

Paul Seniura pdseniura at techie.com
Thu Mar 18 20:58:35 PST 2004

>On Thu, Mar 18, 2004 at 07:51:59PM -0600, Paul Seniura wrote:
>> The discussions on cvs-src list were almost making me
>> panic, so I had to say something quick from another
>> perspective.  My previous msg has header lines pointing to
>> the beginning of that thread, starting with the commits to
>> allow building kernel with icc.  Seems the other
>> respondents here haven't taken time to read them to
>> understand where I'm coming from.  They are/were actually
>> considering publicly distributing kernels built with icc --
>> something we are not privvy to use, as I understand the
>> license, and so must be clearly marked.
Then Brooks Davis wrote:
>I believe you seriously misunderstand the license.  Anyone who holds a
>commercial license may produce binaries that may be used in any way
>they wish.  Thus if the FreeBSD project used its commercial license
>for icc to produce kernel snapshots or ports or whatever, those products
>may be redistribued and used by anyone.

Well, firstly the cvs-src@ discussion had mentioned having
a NON-commercial FREE license granted by Intel after having
asked them, pointedly, for the sake of the o.s. as a
project.  And later it was an UNlimited license mentioned. 
It's clear now that was for distributing what icc puts out
and only that.  It's not a license so I can have and use
icc at work in a legal way (at home here I have OSX+XCode
on G4, and I'd say even icc has some work cut out for it ;) .
And someone on cvs-src@ actually said "icc is free". 
See it for yourself here:
Someone should correct that line "icc is free".
Because it isn't.

I am now corrected.  Thank you.

I'm still at square one, tho. 
It still doesn't help anything I'm doing,
from my perspective as a system programmer. 
Clearly I'm not going to be allowed to use FBSD's keycode
to use icc anywhere, it's not that kind of unlimited
license.  But there's another angle sort-of mentioned in
the URL above.  I'm sure this kind of thing has been
discussed countless times.  It'll do my mental state some
good to spout it off anyway. ;)

Just about all of icc is designed to tweak IA32+s, right? 
So to show off the speed of FreeBSD, let's say re@ builds
CD ISOs with icc tweaked for P3+s, and later the public
pkgs are built with icc similarly tweaked, then perhaps
a two-tier downloadable library ensues.

Right now, 'Free'BSD is created and maintained with 'free'
and open-source tools.  Using icc, it becomes a
conglomeration of mixed licensed materials -- we cannot say
to the world that 'Free'BSD was built in that manner. 
Let users recompile with icc as their choice, but do not
publish CDs or publicly available pkgs with icc, else the
non-profit org might be liable for falsely describing
the products.

...so much for that idea...

Closer to home, I have another problem with icc-built
modules:  Much of our state govmt agency's machines
probably cannot run them: we have older P3s "or less" --
and no money to upgrade, so the politicians here say.

To steer around ACPI and other problems that won't be fixed
by IBM & Intel & Compaq & Delll etc. due to the hardware's
age, and for other reasons, we will need to build custom

On top of that, the pkgs (prebuilt binary 'ready to run' is
how I explain it to the locals) often enough don't have the
knobs (compiled-in features) we'd like to have enabled.

What's more, sometimes the publicly available pkgs as they
stand today don't work on the Puny Pentium2 I and others
are forced to use.  Not until after I have recompiled them
with CPUTYPE=p2 and turning OFF the knobs for SSE "and
higher" functions did the o.s. and ports start acting
predictably.  (Yes my upper-eschelons know about it but
have their hands tied -- no money for upgrading <sigh>.) 
In fact now I am seeing the same bugs as others see while
following CTM src-cur and ports-cur, which lets me relax
somewhat and keep more of my hair. ;) 
Yes recompiling with the 'dumber' tweaks really did make
that kind of difference.

Today/currently I am experimenting with -O2 (mentioned the
other day on another list) -- but the public pkgs and
GENERIC don't have that setting, for the most part. 
OTOH, allowing mplayer to use its original author's -O3
setting made a *huge* difference For The Better on the Puny
Pentium2 -- it's actually usable now. 
Same goes for KDE and its millions of modules with -O2.
But what about the public pkgs. 

Because of these -O tests on 'dumber' Ps, I have been on
record on this list for wanting FBSD maintainers to stop
editting the CFLAGS from the original author's settings. 
They likely have tested it with gcc on i386, we use gcc
on i386, so the original settings ought to stay put. 
OTOH with icc, _more_ logic might need to be added to the
FBSD Makefiles, because the original authors probably will
not have tested their apps with icc.  Oy vey.

There used to be a requirement that libs & apps had to be
compiled similarly.  There were a bunch of 'gotchyas' with
the interplay of different compilers or even different
levels of the same(-flavored) compiler (gcc32, gcc33) or
even different options of the same compiler used for
different modules that had to call each other (or something
like that ;) .

After all this, the msg at the above URL totally agrees
with me in that "we" will not be able to experience any of
the benefits allocated to icc or other such "closed" tools.

Bottom line: the net/tn3270 port I am trying to fix (I
volunteered to be its maintainer, look at its Makefile) can
only be tested with the tools I am allowed to use.  I use
gcc33 with p2 & dumber tweaks at work and I use Apple's
gcc33/XCode usually with -mcpu=7450 at home.  I do intend
on making sure these two platforms (lil & big endians) can
use this emulator, and other platforms should then be
covered.  Having to add _more_ #ifdefs on behalf of _more_
different _compilers_ is out of my hands.

I cannot show TPTB at work "the best of breed".  I have to
show them how things look & act on a Puny Pentium2 (with
items I've bought, to boot, so FBSD would at least support

IMO it'd be better time spent in getting gcc up to par. ;) 
And the GNU teams ought to look at the diffs coming from
Apple & IBM (G4/G5) and OpenDarwin on i386, and others, to
get gcc in _really_ good shape for _all_ platforms. 
(I'm sure the GNU ppl are swamped, it'll take time.) 
Keep our tools free & open, and updatable/fixable by our
own hands, quicker, easier, better...

There... my mental state is all better now...

  --  thx, Paul Seniura.

More information about the freebsd-ports mailing list