Re: [gentoo-dev] system set no longer in part of world set
Robert Bridge wrote: > On Fri, 18 Jul 2008 16:30:20 +0200 > Arfrever Frehtes Taifersar Arahesis <[EMAIL PROTECTED]> wrote: > > > IMHO it would be better to teach users to explicitly specify > > '@system' during updates, e.g. `emerge -uDN @system @world`. > > Why not just re-instate the implicit dependency of world on system? Paludis has "everything" for updating all packages. Would that be an option for portage, too? I.e. `emerge -uDN @everything` -markus P.S.: where does that '@' come from? pgpqvaed2lmAS.pgp Description: PGP signature
Re: [gentoo-dev] strange portage behaviour
Zac Medico wrote:
It's common for people get get confused like this by the "confmem"
behavior that's built into portage's merge process. You can use
--noconfmem to disable it.
Ah, I didn't knew we had this option, thanks for the info. However, a
user complained in [1] that net-dialup/ppp failed to update its
/etc/ppp/ip-{up,down} scripts.
I don't know exactly how it works, but I presume portage will install
the protected files if the checksum of the new file present in $D is
different than the one who was there when the old version were
installed, right?
[1] http://forums.gentoo.org/viewtopic-t-699957.html
signature.asc
Description: OpenPGP digital signature
[gentoo-dev] Re: system set no longer in part of world set
On Fri, 18 Jul 2008 23:13:01 -0600 Ryan Hill <[EMAIL PROTECTED]> wrote: > Just curious, what are the benefits of not having world include > system? Nevermind, I just found your post explaining this. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: system set no longer in part of world set
On Mon, 14 Jul 2008 18:01:23 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > With the new split in Portage where system set packages are not > considered in an "emerge -auDNv world" unless something in world > RDEPENDs on it brings about a few issues. Just curious, what are the benefits of not having world include system? -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
[gentoo-dev] Re: [gentoo-commits] gentoo-x86 commit in eclass: mozcoreconf-2.eclass
On Fri, 18 Jul 2008 17:55:00 +
"Raul Porcel (armin76)" <[EMAIL PROTECTED]> wrote:
> armin76 08/07/18 17:55:00
>
> Modified: mozcoreconf-2.eclass
> Log:
> Enable by default mozilla's optimization
> +IUSE="${IUSE} custom-optimization"
> +
Could you use custom-cflags for this instead?
[EMAIL PROTECTED] ~ $ grep cflag /usr/portage/profiles/use.local.desc
app-crypt/johntheripper:custom-cflags - Enables custom cflags (not supported)
app-emulation/hercules:custom-cflags - Use CFLAGS from /etc/make.conf rather
than the default package CFLAGS (not supported)
app-emulation/xen-tools:custom-cflags - Use CFLAGS from /etc/make.conf rather
than the default Xen CFLAGS (not supported)
app-emulation/xen:custom-cflags - Use CFLAGS from /etc/make.conf rather than
the default Xen CFLAGS (not supported)
games-emulation/zsnes:custom-cflags - Enables custom cflags (not supported)
media-libs/libsdl:custom-cflags - Allow users to use any CFLAGS they like
completely (at their own risk)
media-video/mplayer:custom-cflags - Enables custom CFLAGS (UNSUPPORTED)
sys-boot/grub:custom-cflags - Enables custom cflags (not supported)
x11-drivers/nvidia-drivers:custom-cflags - Build with CFLAGS from
/etc/make.conf (unsupported)
--
gcc-porting, by design, by neglect
treecleaner, for a fact or just for effect
wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662
signature.asc
Description: PGP signature
[gentoo-dev] Re: IBM article of interest ?
On Thu, 17 Jul 2008 11:20:15 -0400 Philip Webb <[EMAIL PROTECTED]> wrote: > 080717 Jeremy Olexa wrote: > > Philip Webb wrote: > >> [2] http://www.ibm.com/developerworks/linux/library/l-awk1.html > >> '03 Jul 2008' has been added since I sent my comment to them > >> yesterday ! However, the incorrect URL for Gentoo Technologies -- > >> www.gentoo.org -- is still there, probably because I didn't > >> mention it in my comment, so I'll try sending them another. > > I don't know all the details or the 'proper' way to handle > > what you are doing. But I wanted to say thanks for spending time on > > this. > > Thanks (big smile) ! It's good to have a bit of encouragement. > > There's really no more to say here: my initial message was about IBM > & I reacted as might any casual reader of their page, > wondering why they were including 8-year-old information re its > author. I did not remember that it was also included in Gentoo docs, > but now do. > > It's clear to me by now that Gentoo does the correct & sensible thing: > reproduce the original as it was in 2000 with a prominent disclaimer. > It's IBM which is not doing that & needs prodding: I've sent another > comment. Are you high? The article was written in 2000. It says so at the beginning. The information in the article pertains to that time. You don't go updating every article you publish every time the author's personal details change. Please leave IBM alone. They were nice enough to allow us to reprint the content of several articles written by Daniel. -- gcc-porting, by design, by neglect treecleaner, for a fact or just for effect wxwidgets @ gentoo EFFD 380E 047A 4B51 D2BD C64F 8AA8 8346 F9A4 0662 signature.asc Description: PGP signature
Re: [gentoo-dev] RFC: auto-detection of unpack dependencies
Marius Mauch kirjoitti: If someone wants to use it I can add it on the tree (after the normal review process and being better tested), but I'll only be doing it when there is an actual demand for it (no point in adding an eclass that nobody uses). I have been long thinking about adding support for .zip handling to java eclasses so let's get this in and it will get a user from java-pkg-2 and java-pkg-opt-2 eclasses at least. Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] system set no longer in part of world set
On Fri, 18 Jul 2008 16:21:24 +0100 Robert Bridge <[EMAIL PROTECTED]> wrote: > On Fri, 18 Jul 2008 16:30:20 +0200 > Arfrever Frehtes Taifersar Arahesis <[EMAIL PROTECTED]> wrote: > > > IMHO it would be better to teach users to explicitly specify > > '@system' during updates, e.g. `emerge -uDN @system @world`. > > Why not just re-instate the implicit dependency of world on system? Because that doesn't actually fix the problem, it just covers it up to some degree (there has never been a guarantee that "system" is actually satisifed when you install a package). Also the new solution is more flexible as it still allows you to include system in world easily, or update/rebuild system and world separately. And for a full system updates there is a new target available that actually includes all installed packages. Yes, this is going to require some user reeducation, and yes, this will take some time, but it isn't as dramatic as some people make it. The whole "implicit-system-dependency" thing has never existed, it was always a broken assumption that only didn't blow up badly because a) the "system" target rarely changes b) most packages only depend on a tiny part of "system" and c) most users actually do full system updates regulary. As soon as you want to install a package that actually implicitly depends on something in "system" that isn't already installed the whole thing breaks down. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
On Fri, 18 Jul 2008 10:01:28 -0400 Doug Goldstein <[EMAIL PROTECTED]> wrote: > Olivier Crête wrote: > > On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: > > > >> This brings out the fun of circular depends. I don't really know > >> how to address this but a lot of packages are going to have to be > >> updated to contain proper depends. i.e. C based apps will need > >> RDEPEND="virtual/libc". C++ packages will need a stdc++ depend. > >> > > > > Adding a dep to libc almost everywhere seems extremely wrong to me. > > I though we had decided many times that it was a bad idea. > > > > > Yes. Adding libc everywhere is wrong. However, if you don't have one > of the packages listed here [1], your libc won't ever update. Now that's a big exaggeration. It _might_ be missing from world updates (there are still many cases where it will be included), but that's not the only available operation in portage. Marius -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] strange portage behaviour
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alin Năstac wrote: > Portage no longer install ._cfg_* files for the CONFIG_PROTECTed > files touched by the user. Even if I remove the package and reinstall it > again, the protected file will remain like it is. > > Can someone enlighten me? > It's common for people get get confused like this by the "confmem" behavior that's built into portage's merge process. You can use - --noconfmem to disable it. In newer versions of portage (those not marked stable yet), uninstalling a package or downgrading it will automatically trigger behavior like --noconfmem [1], so hopefully this will help to avoid some confusion in the future. Zac [1] http://sources.gentoo.org/viewcvs.py/portage?rev=10250&view=rev -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiBG1oACgkQ/ejvha5XGaNf6wCeNZXwZdByfP3pZ2pVoyLh5kYh NqEAn0JddFw6y833/sXrUz2E+O+HQ+ar =7QCy -END PGP SIGNATURE- -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
Perhaps we could write a script that compiles packages in portage with both ICC and GCC and runs them with different flags. I think there was an effort on the GCC side already to test flags with specific packages. We can then have the script run time on the applications doing work (again, that's a lot of packages for a lot of different tasks). If we can store these in the portage tree (yes, it's more metadata), the user can actually benefit well from the optimizations. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
Ciaran McCreesh wrote: How much of that is memory bound? Of the things that aren't, how many aren't written in assembly anyway? Of those things, what proportion of the runtime is spent in those areas? If you double the speed of something that takes up 2% of the overall execution time, you can't measure the improvement. Or looking at it the other way -- is there any reason to believe that using icc (which can end up being a substantial pain in the arse, given the way it tries to use gcc's c++ headers but doesn't support some of the extensions or quirks that g++ does) will provide a genuine gain for people who aren't already doing clever profile-directed trickery anyway? The problem with -O3 is that function inlining can lead to a substantial cache hit. Unless you're using profile-directed optimisations, which Gentoo doesn't support, it's extremely hit and miss as to whether O3 helps or hurts. I agree with all of the above. Gentoo is about choice, so if people want to make ICC work well more power to them. I agree that it would be hard to make it THE ONLY system compiler. For those who do try it I'd be really interested in their findings. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
On Fri, 18 Jul 2008 15:34:53 -0400 Richard Freeman <[EMAIL PROTECTED]> wrote: > Ciaran McCreesh wrote: > > The more interesting question, then, is whether users run any > > non-trivial cpu-bound programs. We know the applied science types > > do, but they tend to be the ones who're doing clever things with icc > > anyway. What about normal users? > > I'm sure they do on some occasion if they encode compressed > audio/video, or when compressing data with zip/etc. That is probably > the biggest application of cpu-bound software. How much of that is memory bound? Of the things that aren't, how many aren't written in assembly anyway? Of those things, what proportion of the runtime is spent in those areas? If you double the speed of something that takes up 2% of the overall execution time, you can't measure the improvement. Or looking at it the other way -- is there any reason to believe that using icc (which can end up being a substantial pain in the arse, given the way it tries to use gcc's c++ headers but doesn't support some of the extensions or quirks that g++ does) will provide a genuine gain for people who aren't already doing clever profile-directed trickery anyway? > I'd probably benefit from using -O3 on the aforementioned > CPU-intensive apps. The problem with -O3 is that function inlining can lead to a substantial cache hit. Unless you're using profile-directed optimisations, which Gentoo doesn't support, it's extremely hit and miss as to whether O3 helps or hurts. -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] Re: ICC Profile
Ciaran McCreesh wrote: The more interesting question, then, is whether users run any non-trivial cpu-bound programs. We know the applied science types do, but they tend to be the ones who're doing clever things with icc anyway. What about normal users? I'm sure they do on some occasion if they encode compressed audio/video, or when compressing data with zip/etc. That is probably the biggest application of cpu-bound software. Personally, I use -Os across the board when it doesn't break. As you said I tend to be memory/IO bound, and optimizing for size helps with both (swapping causes IO). I'd probably benefit from using -O3 on the aforementioned CPU-intensive apps. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
Also, in the academic environment the grad student/university can pay for the license that the student slipstreams into their gentoo installation, making it 100% legal depending on how many seats he or she buys. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] strange portage behaviour
Portage no longer install ._cfg_* files for the CONFIG_PROTECTed files touched by the user. Even if I remove the package and reinstall it again, the protected file will remain like it is. Can someone enlighten me? signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] ICC Profile
On Fri, 18 Jul 2008 15:16:18 +0100 Sébastien Fabbro <[EMAIL PROTECTED]> wrote: > There was some attempts a few years ago for rolling up a full Gentoo > with icc, but it hit several problems if I recall. Now both icc and > gcc have improved since then. Including needing package specific CFLAGS because some packages in @system needed mutually exclusive flag settings. I'll see if I can dig up the link for an old blog on the topic later. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
On Fri, 18 Jul 2008 16:30:20 +0200 Arfrever Frehtes Taifersar Arahesis <[EMAIL PROTECTED]> wrote: > IMHO it would be better to teach users to explicitly specify > '@system' during updates, e.g. `emerge -uDN @system @world`. Why not just re-instate the implicit dependency of world on system? Rob. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] system set no longer in part of world set
Doug Goldstein wrote: Yes. Adding libc everywhere is wrong. However, if you don't have one of the packages listed here [1], your libc won't ever update. Sure it will. When the version of libc you have installed is removed from the portage tree you'll get bumped to the most recent version (stable/testing as appropriate). Works fine for me. I generally don't care if I'm running an older version of libc. If something requires a particular version it will have a dependency and will pull it in. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
He's also doing it on a core 2 duo. It would be interesting to compare this with some mildly legacy hardware (netburst pipelines) in order to see whether GCC does a comparable job. My guess would be no, seeing as netburst was extremely ugly and complicated, only intel would be able to write a compiler that took advantage of it. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
On Fri, 18 Jul 2008 10:24:58 -0400 (EDT) Adam Stylinski <[EMAIL PROTECTED]> wrote: > GCC 4.3 is catching up, but they are no where near utilizing SSE4 or > SSE5 instructions. > > http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html > > He concludes that it's not worth pursuing, but I beg to differ. > Those are signifcant differences for a processor. He doesn't establish whether the code in question is highly cpu-bound or not when run on his system. For a lot of memory- and i/o-bound code, there's little practical difference between gcc with optimisations turned off and gcc with -frice-my-shorts except that the former compiles an order of magnitude faster. The more interesting question, then, is whether users run any non-trivial cpu-bound programs. We know the applied science types do, but they tend to be the ones who're doing clever things with icc anyway. What about normal users? -- Ciaran McCreesh signature.asc Description: PGP signature
Re: [gentoo-dev] system set no longer in part of world set
2008-07-18 16:01:28 Doug Goldstein napisał(a): > Olivier Cr�te wrote: > > On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: > > > >> This brings out the fun of circular depends. I don't really know how to > >> address this but a lot of packages are going to have to be updated to > >> contain proper depends. i.e. C based apps will need > >> RDEPEND="virtual/libc". C++ packages will need a stdc++ depend. > >> > > > > Adding a dep to libc almost everywhere seems extremely wrong to me. I > > though we had decided many times that it was a bad idea. > > > > > Yes. Adding libc everywhere is wrong. However, if you don't have one of > the packages listed here [1], your libc won't ever update. IMHO it would be better to teach users to explicitly specify '@system' during updates, e.g. `emerge -uDN @system @world`. -- Arfrever Frehtes Taifersar Arahesis signature.asc Description: This is a digitally signed message part.
[gentoo-dev] Re: ICC Profile
Branko Badrljica wrote: BTW: Is ICC really worth the fuss ? I have checked around and reported that newest gcc-4.3 is able to to catch and sometimes even outperform icc ( not always, naturally). Big news seemed to be thatnew gcc si close and sometimes better than icc. Is it any truth to that and if it is, what is the motive of having non-open icc option ? The programs where I care about speed the most are gzip, bzip2, oggenc, lame, x264... I guess you get the "pattern", they're encoders/compressors. ICC wins in every one of them (speed increase is quite dramatic in the case of gzip and bzip2; 20% to 30%). GCC won with diffutils though; 2% faster than ICC. Testing other tools is difficult; how do you measure if X is faster with ICC? Or KDE? (If it even compiles with ICC; didnt' test.) There's the issue of bugs though; programs break even with different versions of GCC (see Thunderbird; it breaks when compiled with *any* form of optimization turned on with GCC 4.3. See bugs 223375 and 217805). Who knows what breakage can occur with ICC. The vast majority of projects out there are developed and tested only on GCC systems. Then there's the show stopper #1 bug: every C++ source file that has an #include refuses to compile with ICC (at least on my system; AMD64). Intel responds with "use RedHat where it works, we don't support Gentoo." Supporting ICC in Gentoo is probably going to be too difficult if Intel refuses to even try to fix bugs that don't show up in RedHad and Novell's "enterprise" SUSE. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
GCC 4.3 is catching up, but they are no where near utilizing SSE4 or SSE5 instructions. http://blog.alphagemini.org/2008/03/icc-vs-gcc-43.html He concludes that it's not worth pursuing, but I beg to differ. Those are signifcant differences for a processor. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday July 17, Adam Stylinski wrote: > Pro's: > > 1.) Bloody fast machine code. Intel obfuscates their architecture > but they give back to the community as much as possible to make their > hardware marketable toward the open source sysadmin, developer, etc > etc. Their drivers are open and they develop for the kernel > constantly. This cooperation leads me to believe that they would > assist a team of developers in making 100% icc compatible code. Gentoo is not supported from Intel, and they had not plans doing so. As of October 2007, I asked their Software channel whether Gentoo users have similar support as RedHat or SUSE users and the answer was: "No, we have no current plans to support Gentoo. Also, Gentoo is NOT a derivative of a Linux we do support. My understanding is that it is independently derived from Kernel.org. Thus it is less likely to work than a distro which is a derivative of a supported distribution. Meanwhile, Debian/Ubuntu got support, so things might change if Gentoo re-becomes/remains popular. Any Intel dev reading this list, please contact us. And as Luca mentioned, having sunstudio, xlc (is this one free?) or llvm would not make Intel a privileged case for Gentoo. > 2.) Bloody fast compilation time. In my experience the compiler > works much faster even with heavy optimization. I don't experience this that much, but I really don't use it much either. Would be nice to have benchmarks here. > 4.) will project gentoo toward the power user more, helps the gentoo > image, and overall will make linux a more professional operating > system (and a quite competitive alternative to something like a > SPARC+Solaris configuration). This would also make cluster farms and > science application more respectful toward the gentoo community. The > academic and research world already uses ICC to compile their apps > for the sake of speed. The interprocedural optimizations for both > the fortran and c/c++ compilers make it a must. I would be careful about this, and this needs benchmarks, especially with gcc > 4.3. By default icc flags are fairly agressive. For example, for many scientific applications, you don't want a simple -O2 where you loose floating point precision. Add -mp or -mp1 to your icc flags, add some decent gcc flags, and improvement over gcc is much smaller. > 5.) It's free, albeit a commercial product. As gentoo is entirely > non-profit, there is no restriction when it comes to licensing. The > binaries won't be sold for the intel-compiled livecd, and the > compiler itself with a fetch restriction allows the user to legally > register for their free non-commercial license. Again, as long as you're not being compensated for doing it (for Gentoo I'm not). In summary, I'm completely in favor of trying projects like this, but first, this needs a few benchmarks before going further. - -- Sébastien -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiApcoACgkQ1ycZbhPLE2C0TQCfYLD2+mazHKjosK7wiHFU6FGb d3EAnR1FWZ92O2B9xBJerCj4dj2GRUZ4 =YhT2 -END PGP SIGNATURE- ���^�X��� ��(��&j)b�b�
Re: [gentoo-dev] ICC Profile
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Apologies if you received this mail already, I'm having problems with my smtp. On Thursday July 17 Adam Stylinski wrote: > The intel C Compiler (icc) has an ebuild for gentoo and the wiki has > a script to integrate it with portage. This script works will in > terms of building binaries, however when mixed with gcc environments > there are massive linking issues. I propose that an ICC profile is > made which contains specific versions and default flags for people > who want to build a mixed icc-gcc environment. ICC is much faster > than GCC and although not free, offers a free non-commercial > license. I would be very interested in this project and more than > willing to help to the best of my abilities. I've already been > trying to maintain a mixed environment with some luck, while there > have been a lot of problems using dynamically linked libraries (ld > from intel and ld from gcc don't always get along), my system is > substatially faster. The kernel obviously will still be built under > gcc as well as bash (unless intel helps submit patches to make the > code work with their compiler). There are many tools icc ! has to > offer for vectorization. If these were streamlined into Gentoo with > a fetch restriction for ICC, a bootsrapping boot disk could be made > and result in a very fast distribution. An icc profile would be welcome. I've been the maintainer of icc (and other Intel tools) for the last year or so more by default than real interest. I would welcome any input from the Gentoo community. Re-adding slots and an icc profile was on my mind, but never found the time to invest in it, and got at the tail of my priority list. So don't hesitate to contact me (email, irc, bugs) and others. There was some attempts a few years ago for rolling up a full Gentoo with icc, but it hit several problems if I recall. Now both icc and gcc have improved since then. Also, if you haven't already, check also some of the old bugs [1,2] we have, and a recurring one [3]. I would like to recall one important issue with the Intel license concerning the "free for non-commercial use" [4]. It means you can't use it for free if you're paid to use it. Yes, beer is not free for academic scientists too. [1] http://bugs.gentoo.org/show_bug.cgi?id=26757 [2] http://bugs.gentoo.org/show_bug.cgi?id=53808 [3] http://bugs.gentoo.org/show_bug.cgi?id=201596 [4] http://www.intel.com/cd/software/products/asmo-na/eng/219692.htm#0 - - -- Sébastien -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkiApboACgkQ1ycZbhPLE2BMHgCggfzfS4SakVyw42r+JnnxYNpL E9gAoJvRrocinIDlInF6kbeSGF2kvX9t =M4XK -END PGP SIGNATURE-
Re: [gentoo-dev] system set no longer in part of world set
Olivier Crête wrote: On Mon, 2008-07-14 at 18:01 -0400, Doug Goldstein wrote: This brings out the fun of circular depends. I don't really know how to address this but a lot of packages are going to have to be updated to contain proper depends. i.e. C based apps will need RDEPEND="virtual/libc". C++ packages will need a stdc++ depend. Adding a dep to libc almost everywhere seems extremely wrong to me. I though we had decided many times that it was a bad idea. Yes. Adding libc everywhere is wrong. However, if you don't have one of the packages listed here [1], your libc won't ever update. [1] http://tinderbox.dev.gentoo.org/misc/rindex/virtual/libc -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
Robert Bridge wrote: On Fri, 18 Jul 2008 11:34:11 +0900 Luca Barbato <[EMAIL PROTECTED]> wrote: Adam Stylinski wrote: The intel C Compiler (icc) icc, xlc, llvm, sunstudio could be interesting fields of discovery. Which are the pitfalls of using icc? lu If I recall correctly, needing some packages compiled with ICC flags set one way, and needing others compiled with the same flag set the oter way. Can it compile a kernel yet? Rob. No. It doesn't implement all of GCCs extensions and all GNUisms that the kernel relies on. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
BTW: Is ICC really worth the fuss ? I have checked around and reported that newest gcc-4.3 is able to to catch and sometimes even outperform icc ( not always, naturally). Big news seemed to be thatnew gcc si close and sometimes better than icc. Is it any truth to that and if it is, what is the motive of having non-open icc option ? Adam Stylinski wrote: I actually know somebody working at intel, maybe he can get them more involved. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] Re: ICC Profile
I actually know somebody working at intel, maybe he can get them more involved. -- gentoo-dev@lists.gentoo.org mailing list
Re: [gentoo-dev] ICC Profile
I'm not suggesting that it be sold. Gentoo is non-profit anyway, the livecd could be available for download only. The binaries don't have to be licensed if you're not selling them, however the compiler does. This is where the non-commercial free license comes in (with a fetch restriction requiring the user to register for it). This is completely free and I don't see it much more of a pain than it is to go sign up for the IBM developers work to extract their PPC version of java. -- gentoo-dev@lists.gentoo.org mailing list
[gentoo-dev] Re: ICC Profile
Adam Stylinski wrote: The intel C Compiler (icc) has an ebuild for gentoo and the wiki has a script to integrate it with portage. I'm using ICC for programs where I have numbers about performance; for example, bzip2 is 30% faster here when compiled with ICC. However, one thing I don't like about ICC is that when you post in the Intel forums about a problem you have on Gentoo, the reply is "Gentoo is not supported, please use RedHat." If Gentoo is going to "support" ICC, ICC should be supporting Gentoo as well. -- gentoo-dev@lists.gentoo.org mailing list
