Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
ICC / IFC 8.0 is out!
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next  
Reply to topic    Gentoo Forums Forum Index Portage & Programming
View previous topic :: View next topic  
Author Message
fumtu99
n00b
n00b


Joined: 05 Sep 2002
Posts: 59

PostPosted: Tue Jan 06, 2004 11:55 pm    Post subject: Reply with quote

I tried setting my environment up to use ICC and re-emerged cdrtools. While doing do, I noticed that most (if not all) of the compiler's output is masked by the cdrtools make file setup - if you go poking around in there, you'll discover that GCC is hard-coded into those make files, and AFAIK, there's nothing in the ebuild files for cdrtools to patch this; timing the resulting binries' executions confirmed that they were NOT compiled with ICC. Since I was poking around in there, anyway, I was able to manually edit some configuration files and get it to build properly with ICC, as well, but I haven't figured out how I'd make such changes to the ebuild file, so that it'd definitely work there - the make files are set up to use different configuration files, dependent on the processor type, O/S, etc., and to this point I haven't figured out how to get the same to happen under Portage, as far as patching the correct configuration file is concerned. So, I guess that what I'm saying here is that while the ebuild "works" with ICC, it's not exactly a no-brainer to make it REALLY work; I think that the list of things that work w/ ICC should be updated to reflect this, if it's supposed to be of things that are supposed to be easy to get to work (set some environment variables and re-emerge). Also, while QT will compile with ICC, it'll tend to break rebuilding k3b (at least) - k3b's configuration system will bomb out, complaining that you haven't installed kdelibs, while the REAL problem is that QT and kdelibs were compiled with different compilers. I suspect that it would still link properly, if the configuration system weren't so picky, but I haven't tried to force it (yet)... and at least the last time I checked, it was still a problem to get kdelibs to work under ICC... Oh well, what I REALLY want to do is just get my burner working faster - I think I'll get back to that... and yes, even w/ an Athlon XP (and "-O2 -xK -noalign" as the base flags), cdda2wav and cdrecord are both faster, when cdrtools is compiled with ICC, in the 10-20% range faster!

James
Back to top
View user's profile Send private message
fumtu99
n00b
n00b


Joined: 05 Sep 2002
Posts: 59

PostPosted: Wed Jan 07, 2004 12:31 am    Post subject: Reply with quote

As I just discovered, if you've got ICC installed and "icc" in your USE in make.conf, you'll get an ICC-compiled qt, at least if it's 3.3.0-beta1... I'm going to have to rebuild it w/ GCC, just so I can rebuild k3b! Then I think I can rebuild qt with ICC... Sigh! If only these things didn't take so long to do!

James
Back to top
View user's profile Send private message
NeighborhoodGullwings
Apprentice
Apprentice


Joined: 05 Dec 2003
Posts: 159

PostPosted: Wed Jan 07, 2004 3:33 am    Post subject: Reply with quote

fumtu99: Rather than editing a Makefile, it would be more convenient to re-run the program's configure script to generate a new makefile. Most configure scripts will use environment variables (CC=icc CXX=icpc) to set the appropriate settings in the makefile for the compiler you want.
Back to top
View user's profile Send private message
Snake007uk
Apprentice
Apprentice


Joined: 12 Jan 2003
Posts: 198
Location: London, UK

PostPosted: Wed Jan 07, 2004 3:41 am    Post subject: Reply with quote

im assuming this is the intel version of the c compiler ?

but why would you want to use its what wrong with gcc ?

Snake
_________________
Snake :)

Dual AMD MP 2800+, Asus A7M266-D, 1GB Ram, 18.1GB u160 HD, ATI Radeon 9600 Pro, Creative Audigy ZS, Intel SRCU31A, Linksys NIC, iiyama 18.1 4637bk lcd
Back to top
View user's profile Send private message
goanuj
Tux's lil' helper
Tux's lil' helper


Joined: 13 Jul 2002
Posts: 125
Location: California

PostPosted: Wed Jan 07, 2004 4:36 am    Post subject: using icc Reply with quote

when i downloaded the latest snapshot ftp://mirror.iawnet.sandia.gov/pub/gentoo/snapshots/ it did not have the ebuild for icc 8 ...

how can I force gentoo to use icc 8?
Back to top
View user's profile Send private message
stonent
Veteran
Veteran


Joined: 07 Aug 2003
Posts: 1139
Location: Texas

PostPosted: Wed Jan 07, 2004 5:17 am    Post subject: Reply with quote

Code:
Aurora bash # export LD=xild
Aurora bash # export AR=xiar
Aurora bash # export CC=icc
Aurora bash # export CXX=icc
Aurora bash # emerge -U bash-2.05b-r9.ebuild
>>> --upgradeonly implies --update... adding --update to options.
Calculating dependencies ...done!
>>> emerge (1 of 1) app-shells/bash-2.05b-r9 to /
>>> md5 src_uri ;-) bash-2.05b.tar.gz
>>> md5 src_uri ;-) bash-2.05b-gentoo.diff.bz2
>>> md5 src_uri ;-) bash205b-002
>>> md5 src_uri ;-) bash205b-003
>>> md5 src_uri ;-) bash205b-004
>>> md5 src_uri ;-) bash205b-005
>>> md5 src_uri ;-) bash205b-006
>>> md5 src_uri ;-) bash205b-007
>>> Unpacking source...
>>> Unpacking bash-2.05b.tar.gz to /var/tmp/portage/bash-2.05b-r9/work
 * Applying bash-2.05b-gentoo.diff.bz2...                                 [ ok ]
 * Applying bash205b-002...                                               [ ok ]
 * Applying bash205b-003...                                               [ ok ]
 * Applying bash205b-004...                                               [ ok ]
 * Applying bash205b-005...                                               [ ok ]
 * Applying bash205b-006...                                               [ ok ]
 * Applying bash205b-007...                                               [ ok ]
 * Applying bash-2.05b-multibyte-locale.patch...                          [ ok ]
 * Applying bash-2.05b-empty-herestring.patch...                          [ ok ]
 * Applying bash-2.05b-rbash.patch...                                     [ ok ]
>>> Source unpacked.
configure: WARNING: If you wanted to set the --build type, don't use --host.
    If a cross compiler is detected then cross compile mode will be used.
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu

Beginning configuration for bash-2.05b-release for i686-pc-linux-gnu

checking for i686-pc-linux-gnu-gcc... icc
checking for C compiler default output... configure: error: C compiler cannot cr                                                                                     
eate executables

!!! ERROR: app-shells/bash-2.05b-r9 failed.
!!! Function econf, Line 339, Exitcode 77
!!! econf failed


However:

Code:
Aurora bin # icc test.c
Aurora bin # file a.out
a.out: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.4.1, dynamically linked (uses shared libs), not stripped
Aurora bin #

_________________
Inspiron 4100 & Sun UltraAXe
Portage on Solaris|Dell Laptop Hacks
The way you feel about organized religion is the same way I feel about organized socialism.
Back to top
View user's profile Send private message
fumtu99
n00b
n00b


Joined: 05 Sep 2002
Posts: 59

PostPosted: Wed Jan 07, 2004 3:17 pm    Post subject: Reply with quote

Quote:
fumtu99: Rather than editing a Makefile, it would be more convenient to re-run the program's configure script to generate a new makefile. Most configure scripts will use environment variables (CC=icc CXX=icpc) to set the appropriate settings in the makefile for the compiler you want.


Well, I agree, but the cdrtools scripts ignore those environment variables and set their own values; IIRC, I had to perform the same editing of files that the latest ebuild does (to set the installation paths - it uses sed, but I did it mannually), and modify conf/Defaults.linux to use ICC and create a file called "RULES/i686-linux-icc.rul" , to pass along the compiler flags I wanted. After doing this, I was able to run the configure script in the conf directory. The problem with incorporating all of this into the ebuild file is the creation of that last file, since its name is build up dynamically, although I suppose it'd be possible to just create a whole family of them for all the Intel processor types expected (you wouldn't be using ICC, otherwise), since I think that that is the only part of the name that'd vary, here... Either that, or create one such file and links to all the names needed. Hmm! That might be something I could get into an ebuild file; I think I'll try doing that!

James
Back to top
View user's profile Send private message
dabooty
Guru
Guru


Joined: 15 May 2003
Posts: 482
Location: Belgium

PostPosted: Wed Jan 07, 2004 5:24 pm    Post subject: Reply with quote

Snake007uk wrote:
im assuming this is the intel version of the c compiler ?

but why would you want to use its what wrong with gcc ?


speed
_________________
registered user #284425
get yourself counted
http://counter.li.org
------
#emerge -pv solves a lot of questions beforehand
Back to top
View user's profile Send private message
discomfitor
l33t
l33t


Joined: 21 Feb 2003
Posts: 927
Location: None

PostPosted: Wed Jan 07, 2004 10:11 pm    Post subject: Reply with quote

fumtu99: if you're going to try compiling k3b with icc, you need kdelibs compiled with icc too.
_________________
There is no substitute for experience.
Imperfection indicates a lack of effort.
Back to top
View user's profile Send private message
dabooty
Guru
Guru


Joined: 15 May 2003
Posts: 482
Location: Belgium

PostPosted: Thu Jan 08, 2004 6:09 pm    Post subject: Reply with quote

and compiling kdelibs with icc, will most likely break the rest of kde, which you'll need to compile with icc too, which will never work.
It gets very tricky when you try to recompile interdependent packages, which is why i've decided to not bother with this compiler until it compiles most of the packages or the gentoo maintainers get the icc use flag working
_________________
registered user #284425
get yourself counted
http://counter.li.org
------
#emerge -pv solves a lot of questions beforehand
Back to top
View user's profile Send private message
dabooty
Guru
Guru


Joined: 15 May 2003
Posts: 482
Location: Belgium

PostPosted: Thu Jan 08, 2004 6:15 pm    Post subject: Reply with quote

FYI, these are my findings from experimenting with ICC
I noticed some things possibly wrong in the original post also:
- cdrtools compiles, but it doesn't look as if it uses ICC
- jpeg compiles but breaks a lot of stuff

here they are:

Program Compiles Effects
cdrtools-2.01_alpha14 YES Doesn't look like it uses icc imo, hides compile commands and gives no warnings
bin86-0.16.0 YES Fairly clean, some code warnings
bzip2-1.0.2-r2 YES Some warnings
findutils-4.1.7-r5 YES Near clean compile
fluxbox-0.9.6 NO Goes a long way with a lot of warnings, but fails
grep-2.5.1-r1 NO Fails on code errors
Jpeg-6b-r3 WARN Compiles but leads to random crashes (IE firebird, nautilus)
lame-3.93.1-r1 YES ICC seems actually slower
man-1.5l-r6 YES Quite a few warnings but works
mpg123-0.59r-r3 YES Warnings
nano-1.3.0 NO See bug 36668 (reported to compile in post)
rhythmbox-0.6.3 NO Fails almost immediately
rsync-2.5.7 YES Fairly clean loads of vectorizing
Sed-4.0.7 NO Fails with code warnings
slocate-2.7-r2 YES Near clean compile
tar-1.13.25-r3 NO Fails after loads of warnings
unzip-5.50-r2 YES Lots of warnings, marginal improvements
xine-lib-1_rc2 NO Goes a long way with a lot of warnings, but fails
zip-2.3-r2 NO Hardcoded profiles in makefile set compiler back to gcc
Bzip2-1.0.2-r3 YES Warnings
gawk-3.1.3-r1 NO Fails with code warnings
Bison-1.875 YES Warnings
dia-0.92_pre7 NO Almost instantly
texinfo-4.5 YES Some warnings
grip-3.0.3 NO Fails after warnings
_________________
registered user #284425
get yourself counted
http://counter.li.org
------
#emerge -pv solves a lot of questions beforehand
Back to top
View user's profile Send private message
stonent
Veteran
Veteran


Joined: 07 Aug 2003
Posts: 1139
Location: Texas

PostPosted: Thu Jan 08, 2004 7:15 pm    Post subject: Reply with quote

I'm wondering why I can't get anything to compile with ICC. I emerged the latest e-build from bugs.gentoo.org, added icc to my use settings. exported cc=icc and cxx=icc added my license but it says it can't create executables.

I had icc7 at one time and it worked fine.
_________________
Inspiron 4100 & Sun UltraAXe
Portage on Solaris|Dell Laptop Hacks
The way you feel about organized religion is the same way I feel about organized socialism.
Back to top
View user's profile Send private message
dabooty
Guru
Guru


Joined: 15 May 2003
Posts: 482
Location: Belgium

PostPosted: Thu Jan 08, 2004 7:21 pm    Post subject: Reply with quote

stonent wrote:

but it says it can't create executables.

do you have portage features like distcc or ccache enabled?
_________________
registered user #284425
get yourself counted
http://counter.li.org
------
#emerge -pv solves a lot of questions beforehand
Back to top
View user's profile Send private message
stonent
Veteran
Veteran


Joined: 07 Aug 2003
Posts: 1139
Location: Texas

PostPosted: Thu Jan 08, 2004 8:56 pm    Post subject: Reply with quote

Nope, I even stripped down my cflags (see earlier post in this thread) I can compile icc file.c but when make runs it says can't create executables.
_________________
Inspiron 4100 & Sun UltraAXe
Portage on Solaris|Dell Laptop Hacks
The way you feel about organized religion is the same way I feel about organized socialism.
Back to top
View user's profile Send private message
sindre
Guru
Guru


Joined: 01 Nov 2002
Posts: 315
Location: Norway

PostPosted: Fri Jan 09, 2004 3:34 pm    Post subject: Reply with quote

xfree-4.3.99.902 compiles with cflags=""

edit: everything kde seems to segfault now... will the -cxxlib-gcc flag help this?

edit2: Niceness! Now I can't recompile xfree because something segfaults.

Quote:
making all in programs/xkbcomp/compat...
make[5]: Entering directory `/var/tmp/portage/xfree-4.3.99.902/work/xc/programs/xkbcomp/compat'
rm -f compat.dir
LD_LIBRARY_PATH=../../../exports/lib ../../../exports/bin/xkbcomp -lfhlpR -o compat.dir '*'
make[5]: *** [compat.dir] Segmentation fault
make[5]: *** Deleting file `compat.dir'
make[5]: Leaving directory `/var/tmp/portage/xfree-4.3.99.902/work/xc/programs/xkbcomp/compat'
make[4]: *** [all] Error 2
make[4]: Leaving directory `/var/tmp/portage/xfree-4.3.99.902/work/xc/programs/xkbcomp'
make[3]: *** [all] Error 2
make[3]: Leaving directory `/var/tmp/portage/xfree-4.3.99.902/work/xc/programs'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/portage/xfree-4.3.99.902/work/xc'
make[1]: *** [World] Error 2
make[1]: Leaving directory `/var/tmp/portage/xfree-4.3.99.902/work/xc'
make: *** [World] Error 2

!!! ERROR: x11-base/xfree-4.3.99.902 failed.
!!! Function src_compile, Line 468, Exitcode 2
!!! (no error message)
Back to top
View user's profile Send private message
Cheesefoam
Tux's lil' helper
Tux's lil' helper


Joined: 02 Jan 2003
Posts: 89

PostPosted: Fri Jan 09, 2004 9:32 pm    Post subject: Reply with quote

Sorry it's been a good long while since I posted last. Anyways, here's a couple of pointers on trying to get things to emerge with ICC. The easiest way to do it is to make a script which automatically sets all of the variables you will need for the emerge, then calls emerge to do the actual dirty work. Note that you *should* set the AR and LD variables in addition to CC and CXX, because it helps tremendously in terms of a compilation actually working if you use the intel ones instead of the GNU ones.

Code:

export AR=xiar LD=xild CC=icc CXX=icc

#if you want to use the intel fortran compiler:
#export FF=ifc FORTRAN=ifc FC=ifc

emerge $*


As for the bit about not being able to create executables, this goes back to an earlier issue, and one which is the subject of much debate. Whenever you start an emerge, make.conf is read and used to set the CFLAGS and CXXFLAGS variables. Which means if you try to set them on the command line, it doesn't work. ICC throws a fit with certain GCC CFLAGS, and will often bail or spit out other warnings, so you have to either 1) keep a separate line in make.conf commented out except for when using ICC which contains your ICC flags, or 2) use a separate file which contains the variables and which will be called by ebuilds when they are emerged.

The latter approach is the one currently being looked into, which is why there is now an iccifc.conf file in /etc. In this file, all variables are set with an "I" in front of the real name, and can be used by people writing ebuilds to replace the real variables on an as-needed basis. However, this requires modification of any ebuilds which need ICC support - hence the drive to find things which work well with ICC, and which can be modified to support them.

Unfortunately, there is still a lot of instability in icc-land. Especially with the supposed Holy Grail of gcc-library linking support. Since it seems to still be broken, we are left with a compiler that behaves much like 7.0 in terms of compatibility, though a little better. Until Intel actually fixes the cxx-lib flags to make it work across more glibc versions, it's still just a guessing game, and you won't see broad ICC support at all.
Back to top
View user's profile Send private message
fumtu99
n00b
n00b


Joined: 05 Sep 2002
Posts: 59

PostPosted: Sun Jan 18, 2004 5:57 am    Post subject: Reply with quote

Quote:
fumtu99: if you're going to try compiling k3b with icc, you need kdelibs compiled with icc too.


I'm NOT trying to compile k3b with ICC, mainly because it was apparent that kdelibs would need to be compiled with ICC, too, and after looking at an attempt at doing that, I agree - it doesn't work, at least not without quite a bit of hacking. The problem was that whether I wanted it or not, Qt WOULD compile with ICC, the way Qt's ebuild was set up, if "icc" was included in the USE environment variable in /etc/make.conf, and that that library had been updated (and hence recompiled with ICC) recently, which would cause k3b's build to fail, since its configure script checks to make sure that kdelibs and Qt are both compiled with the same compiler. The easiest way to fix this would probably be to remove "icc" from the USE variable, but I sort of like to leave it there and see if any ebuilds pay attention to it, so instead I did the

USE="-icc" emerge qt

trick, to switch that variable off for just that one library. That way, things that use Qt may run a little slower, but at least it doesn't seem to hose up KDE-based applications.

It's been a little while since I posted here - got distracted by some other things, but I notice Cheesefoam (great name, BTW) saying that the environment variables in make.conf override variables set on the command line; I don't think that this is true - otherwise, that trick described above (and in many, many other postings in these forums) would not work. I've also been able to use the setting of CC, CXX, CFLAGS, CXXFLAGS, AR and LD environment variables to values appropriate for the Intel software, then run "emerge shorten", for example, and seen that it built the software with ICC instead of GCC, and the resulting program seems to run faster and produce identical results when given the same inputs. (This isn't always the case, BTW - cdparanoia, for one, seems to run a bit slower, possibly because it uses 64-bit long arithmetic, which a guy on Slashdot recently determined was something that GCC does significantly more efficiently.) Some configure/make implementations for some packages (cdrtools is the one I'm most familiar with) seem to ignore these environment variables, and furthermore, they don't produce the usual verbose output I get with most ebuilds, that shows what compiler is being used; in that case, it's possible (and not hugely difficult) to make a few changes to one configuration file and create another one containing flags to use for ICC, then run configure and make to compile it with ICC, if you don't let emerge automatically delete the work directory it's used to build it with GCC.. So far, I've done this by hand, but I think that it's probably not a huge amount of work to incorporate it into an ebuild file, if you know what you're doing. (I don't, exactly, but I intend to give it a try Real Soon Now, especially since I'm updating my world and see that there's a new cdrtools being built...)

James
Back to top
View user's profile Send private message
goanuj
Tux's lil' helper
Tux's lil' helper


Joined: 13 Jul 2002
Posts: 125
Location: California

PostPosted: Tue Jan 20, 2004 6:44 pm    Post subject: icc in C/C++ Users Journal - February 2004 Reply with quote

Moshe Bar was able to use the Intel 7.0 compiler to compile the Linux Kernel! Basically he said that he got a lot of warnings, but not that many errors. He did have some "minor issues with some drivers (especially e1000.h and ftape-bsm.h). However, some of the errors that he encountered were due to wrongly coded 'typedef' structures like this:"
Code:
typedef struct bar_16{
 char xxx[3];
 short yyy;
} bar_16_t __attribute__ ((aligned (16)));

"Instead, you are supposed to write:"
Code:
typedef struct bar_16{
 char xxx[3];
 short yyy;
} __attribute__ ((aligned (16))) bar_16_t ;

He went on to further say "With the GNU C compiler, the kernal config resulted in a kernel size of 1,523,441, whereas with the Intel compiler, the same configuration yielded a kernel size of only 1,398,289. That's an efficieny difference of 8.9 percent."

So it is possible to compile the linux kernel on x86 using the Intel Compiler! If I have some time I am going to try to replicate his results.
Back to top
View user's profile Send private message
mirko_3
l33t
l33t


Joined: 02 Nov 2003
Posts: 605
Location: Birreria

PostPosted: Tue Jan 20, 2004 7:02 pm    Post subject: Reply with quote

of course, now we want to know how much faster the kernel really is.. :D
_________________
Non fa male! Non fa male!
Back to top
View user's profile Send private message
goanuj
Tux's lil' helper
Tux's lil' helper


Joined: 13 Jul 2002
Posts: 125
Location: California

PostPosted: Tue Jan 20, 2004 9:56 pm    Post subject: re: how much faster the kernel really is Reply with quote

ok, here is the graph from CUJ: (please bear in mind that the author [Moshe Bar] was using an older version of gcc and icc)
Code:
         Signal  Fork    Conext Switch   VM Page Delete  Pipe Create
GCC 3.1  3.73    15.61   164.3           379.2           4.28
p70      3.61    15.64   163.8           417.7           4.17
pgo      3.42    15.50   163.2           409.3           4.18
pgoipo   2.76    13.32   163.2           376.3           4.07
inline   2.77    13.40   163.9           388.6           4.12

Benchmark results. UniProcessor, P4 2.4Ghz. time is in microseconds. p70, the kernel built by just with the -O2 optimization (Intel Compiler 7.0). pgoipo=p70 + pgo(profile-guided optimization) + ipo(interprocedural optimization). inline=pgoipo + forced inline.

Take all these benchmarks with a grain of salt, (ie don't start a religious war between compilers and optimizations). It is merely a table, and I don't think anyone on this forum has been able to replicate the results. The author also mentions "The kernels built by GCC 3.2 were not stable on the Pentium 4, so I used GCC version 3.1.) As a customary warning/notice for every benchmark is neither scientific nor audited. You may achieve slightly different results in your environment. the results are an indication rather than an absolute judgment of the quality of any of the compilers used. As usual, your mileage may vary."

Signal measures the time for the kernel to deliver a signal to a process.
Fork measures the time for the kernel to creaet an ex novo process and all the related address space structures.
Context Switch time is a measurement of the microseconds it takes to switch from user space to kernel space upon hardware interrupts.
VM Page Delete indicates how long it takes the virtual memory manager of the kernel to remove a page table entry and all depending kernel lists.
Pipe Create measures the time to build a pipe connection beween two processes.
Back to top
View user's profile Send private message
corrosif
Apprentice
Apprentice


Joined: 21 Dec 2003
Posts: 184
Location: France

PostPosted: Fri Jan 30, 2004 10:26 pm    Post subject: How to specify the path to ICC? Reply with quote

I have a little problem: I have installed ICC 8.0.055 with the latest ebuild proposed by bugs.gentoo.org.

Now I have it under /opt/intel/compiler80

... but no path to it is specified in the environment, that's why I tried to add the bin, include and lib directories in my $PATH.

With it, I get the following messages while trying to compile and execute a basic Hello World program:

$ icc hello.c -o hello
$ ./hello
./hello: error while loading shared libraries: libcprts.so.5: cannot open shared object file: No such file or directory

What should I do to specify a correct environment for ICC?
_________________
S'il n'y a pas de solution, alors il n'y a pas de problème (logique Shadok).
Back to top
View user's profile Send private message
yamakawa
Guru
Guru


Joined: 28 Jul 2003
Posts: 340

PostPosted: Mon Feb 02, 2004 1:31 pm    Post subject: Reply with quote

I tried this code
Code:
# emerge -evp world|grep icc

and see what I got...
Code:
[ebuild  N    ] x11-misc/xscreensaver-4.14-r1  +gnome +gtk +gtk2 +icc +jpeg -kerberos -krb4 +opengl +pam -xinerama  3,894 kB
[ebuild  N    ] dev-lang/icc-8.0.055   0 kB *1

Is xscreensaver the only package which supports icc compiling? If so, what the big difference is there with or without icc?
Back to top
View user's profile Send private message
NeighborhoodGullwings
Apprentice
Apprentice


Joined: 05 Dec 2003
Posts: 159

PostPosted: Mon Feb 02, 2004 10:45 pm    Post subject: Reply with quote

No that only means that one package in your world has the icc use flag. You can use icc with lots of programs by just setting the environment variables before you emerge them. The icc use flag is there in some ebuilds to do that for you but there are only a few.
Back to top
View user's profile Send private message
yamakawa
Guru
Guru


Joined: 28 Jul 2003
Posts: 340

PostPosted: Tue Feb 03, 2004 7:52 pm    Post subject: Reply with quote

NeighborhoodGullwings wrote:
No that only means that one package in your world has the icc use flag. You can use icc with lots of programs by just setting the environment variables before you emerge them. The icc use flag is there in some ebuilds to do that for you but there are only a few.


Now I get it. That explains the long list of the software on the first page. Thanks for kind explanation.
Back to top
View user's profile Send private message
sumin k'adra
n00b
n00b


Joined: 20 Sep 2003
Posts: 65
Location: santa fe, nm

PostPosted: Mon Feb 09, 2004 1:04 am    Post subject: Reply with quote

Just thought I'd add a few programs I've got working...

jack-audio-connection-kit (v. 0.80 and 0.94)
ecasound
ecamegapedal - have yet to see if there is any speed/effeciency differences

libvorbis - breaks alsaplayer, which isn't icc friendly (-lstdc++)
vorbistools - 5-10% slower on my athlon-xp

xvid (1.0.0 rc1) 10-15% faster on my athlon-xp

unfortuately I can't get the following to compile with icc:

transcode - complains about -lstdc++. If I figure that out I'm going to try all the misc dvd libraries to see if any of them can be sped up.

ladpsa - need to fudge with the Makefile by hand I think...

-sk

BTW, it would be nice if the front page listed which packages are libraries that will break any non icc-compilable programs. Such as libpng and jpeg breaking Mozilla-Firebird, etc.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Portage & Programming All times are GMT
Goto page Previous  1, 2, 3, 4, 5, 6, 7  Next
Page 5 of 7

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum