Re: [gentoo-user] gcc 4.1.1 to 4.1.2 - need to rebuild system?
On Sonntag, 20. Mai 2007, Denis wrote: I am upgrading from gcc-4.1.1-rX to gcc-4.1.2... Is it safe to just emerge the new version yes , or do I need to do emerge -eav system and emerge -eav world, as the gcc upgrade guide suggests? Do I need to rebuild libtool every time I upgrade gcc? no. This is only a 'minor' version update. You don't need anything to do. All the steps in the upgrade guide are there if you upgrade from one major release to anoter (like 3.X to 4.X or maybe 4.1 to 4.2) -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gcc 4.1.1 to 4.1.2 - need to rebuild system?
Denis wrote: I am upgrading from gcc-4.1.1-rX to gcc-4.1.2... Is it safe to just emerge the new version, or do I need to do emerge -eav system and emerge -eav world, as the gcc upgrade guide suggests? Do I need to rebuild libtool every time I upgrade gcc? Thanks! Denis Since this is a minor upgrade, I don't think you have to do anything. I updated mine and whatever else got updated and left it at that. I think the only time you have to do a emerge -e world is when you do a major upgrade like from 3.* to 4.* or the next 5.* which I assume will be coming at some point. Hope that helps. Dale :-) :-) :-) :-) -- www.myspace.com/-remove-me-dalek1967 Copy n paste then remove the -remove-me- part. -- [EMAIL PROTECTED] mailing list
Re: [gentoo-user] gcc-4.1.1 and realplayer-10.0.7
quoth the Peter: It appears that the realplayer binary still requires libstdc++.so.5 which is provided by libstdc++-v3-3.3.4. So despite the fact that this library may not be needed for recompiled c++ apps, binary ones like this may still require the old library :( ldd realplay.bin ... libstdc++.so.5 = not found $ ldd /opt/RealPlayer/realplay.bin | grep libstdc++ libstdc++.so.5 = /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 (0xa79c5000) $ epm -qf /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.6/libstdc++.so.5 gcc-3.3.6 Did you not keep gcc-3.3.6 slotted? Filed a bug? Peter -d -- darren kirby :: Part of the problem since 1976 :: http://badcomputer.org ...the number of UNIX installations has grown to 10, with more expected... - Dennis Ritchie and Ken Thompson, June 1972 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 missing g++/c++
I don't believe that I included the USE=nocxx variable. You can simply check with emerge -pv gcc. Yes, I must have included the nocxx in my use variable since a re-build of GCC included the g++ compiler. From this point forward all packages using C++ would build with out errors. However, the package media-libs/netpbm-10.34 is failing with the following error: flex -t thinkjettopbm.l thinkjettopbm.c1 NONE:0: /usr/bin/m4: ERROR: EOF in argument list make[2]: *** [thinkjettopbm.c1] Error 1 make[2]: Leaving directory `/var/tmp/portage/netpbm-10.34/work/netpbm-10.34/converter/pbm' make[1]: *** [pbm/all] Error 2 make[1]: Leaving directory `/var/tmp/portage/netpbm-10.34/work/netpbm-10.34/converter' make: *** [converter/all] Error 2 !!! ERROR: media-libs/netpbm-10.34 failed. Call stack: ebuild.sh, line 1543: Called dyn_compile ebuild.sh, line 938: Called src_compile netpbm-10.34.ebuild, line 97: Called die !!! (no error message) !!! If you need support, post the topmost build error, and the call stack if relevant. Thanks for the help. Regards, Richard Broersma Jr. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 missing g++/c++
Am Samstag, 12. August 2006 09:05 schrieb ext Richard Broersma Jr: I don't believe that I included the USE=nocxx variable. You can simply check with emerge -pv gcc. Bye... Dirk -- Dirk Heinrichs | Tel: +49 (0)162 234 3408 Configuration Manager | Fax: +49 (0)211 47068 111 Capgemini Deutschland | Mail: [EMAIL PROTECTED] Hambornerstraße 55 | Web: http://www.capgemini.com D-40472 Düsseldorf | ICQ#: 110037733 GPG Public Key C2E467BB | Keyserver: www.keyserver.net pgpahxEHgZm5x.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 missing g++/c++
Unless you are crazy enough to have USE=nocxx, you get a c++ compiler with gcc. Others are controlled by USE flags. I don't believe that I included the USE=nocxx variable. I will give another try at re-building GCC a little later just to see if I get the same effect. (Honestly, I did add a few additional Use Flags before I emerge gcc. gdj and fortran were some of them. I went through and pruned a few of them when I first started having problems with some of packages failing to emerge.) gcj - java compiler fortran - fortran compiler ...and so on. ncurces, groff, sys-libs/db, python All fail with the same error What error? These various errors sound very similar. Here is an error I've transposed from the last package in the emerge --resume --skipfirst. ../../build-aux/depcomp:line 512: execg++ not found make[4]: *** [calc++-scanner.o] Error 127 Other packages will give up during the sanity check when they discovered there wasn't a g++ compiler for available. Thanks for the reply. Regards, Richard Broersma Jr. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 missing g++/c++
On 8/12/06, Richard Broersma Jr [EMAIL PROTECTED] wrote: Unless you are crazy enough to have USE=nocxx, you get a c++ compiler with gcc. Others are controlled by USE flags. I don't believe that I included the USE=nocxx variable. I will give another try at re-building GCC a little later just to see if I get the same effect. (Honestly, I did add a few additional Use Flags before I emerge gcc. gdj and fortran were some of them. I went through and pruned a few of them when I first started having problems with some of packages failing to emerge.) Ok. Don't forget to use eselect compiler (or gcc-config) to select the 4.1.1 compiler after you have merged it if you want to use it. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Bob Young wrote: Depends on what you consider sufficient. Although what the page recommends was misquoted, it actually suggests: emerge -e system emerge -e system emerge -e world emerge -e world That's probably is a little bit excessive, but the reason for doing the two emerge -e systems is so that the new tool chain is built with the new tool chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler. What you actually want is a gcc-4.1.1 that was built with gcc-4.1.1. You could emerge the compiler twice before doing the emerge -e system, but the the emerges that happen before glibc is rebuilt are linked against a glibc that was built with the old compiler. Same with the rest of the tool chain and libraries. Hmm ... unless the build of gcc has changed over the years, it used to build the compiler as a bootstrap and then use new compiler (xgcc) to build the final compiler for install (gcc). Thus, the standard make script already builds the compiler twice. I don't know that a compiler rebuild is really necessary when binutils is updated. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Bob Young wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Fish Sent: Wednesday, June 07, 2006 9:24 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 On 6/7/06, Bob Young [EMAIL PROTECTED] wrote: chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler. This is false. Gcc uses itself to build itself. It uses the system compiler to build an initial version of itself, and then uses that version to build itself. And then for good measure, it uses that version to build the final version. It's called a 3-stage bootstrap, and is documented in the file INSTALL/build.html in the gcc sources. You can also look at /usr/portage/eclass/toolchain.eclass to determine that Gentoo uses the bootstrap-lean target by default. No, sorry that's just wrong. gcc is slotted, if the above were true there would be no need for gcc-config in order to select a default compiler. When a new compiler is emerged, it does *not* automatically become the default system compiler, it must be selected, and that can only happen after it has successfully been emerged. The first time a new gcc compiler is emerged, it is indeed built with the previous version of the compiler that is currently istalled as the system default. xgcc is built with the previous system compiler. Then xgcc is used to build the new gcc for installation. The final install is a self-built gcc and is not built by the previous system compiler. Frankly, anybody who claims that gcc needs to be merged twice so it can be built with itself and produce better object code does not have a clue what they are talking about and you should simply disregard anything else they have to say about what is necessary/useful when upgrading gcc. It does have to be emerged twice in order for it to be built with itself, anybody who thinks otherwise doesn't understand the basic principles of compiling and linking. I think you have ignored what the previous poster suggested. happen before glibc is rebuilt are linked against a glibc that was built with the old compiler. And guess what difference this makes to the end result. None. Nada. Nothing. Because for basically every program on your system, they are *dynamically linked* against glibc. Are you absolutely 100% sure that every single system utility and application is *dynamically* linked, and that no apps or utilities anywhere in the system specifies *static* linking? There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Really, so people who intentionally and specifically want to upgrade absolutely *everything* should not worry about what gets left out because Richard says it's unimportant? The issue is about upgrading gcc and even the gcc upgrade howto recommends an emerge -e world. It's clear that gcc it self at least has to be emerged twice in order to build the new gcc *with* the new gcc. Wrong. The gcc package builds a bootstrap compiler (the new version), called xgcc and then it uses that to build [after some tests] the final installed gcc. A single emerge of gcc will create a compiler that was built by itself. Thus, if you move from 3.3.4 to 4.1.0: emerge -u gcc You WILL have a gcc that was compiled by a 4.1.0 compiler. Whether this is strictly necessary or not is certaintly debatable, but since it executes fairly quickly, and seems a prudent step, I'd argue that it's a reasonable course. Of course a selecting the new gcc as the default with gcc-config is also required in between, but that's self evident. Adding gcc-config, glibc, binutils, libstdc++-v3, quickly covers the most important parts of the basic tool chain, and covers most utilities or apps that might specify static linking, and executes much much faster than an emerge -e system. There is no value to having glibc or libstdc++-v3 in the first line. There is no value at all to doing that twice. Twice is the only way to build the new gcc *with* the new gcc. I should have added the gcc-config select command in between, but I thought that was pretty clearly necessary. You didn't pay attention to what he wrote. I hope perhaps my post made it more clear. Tom Veldhouse -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] gcc-4.1.1
-Original Message- From: Thomas T. Veldhouse [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 10:25 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 You didn't pay attention to what he wrote. I hope perhaps my post made it more clear. Tom Veldhouse The only thing your post made clear is that you don't bother to read all of a thread before replying to it. Maybe this will help: The following reply was sent by me on Thur 6/8/2006 7:57 AM * -Original Message- From: Bo Ørsted Andresen [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 7:29 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 Thursday 08 June 2006 16:00 skrev Bob Young: Show me some documentation for this staging you refer to. If you unpack the gcc sources you will find it in gcc-*/INSTALL/build.html as already mentioned by Richard. But you can also see it at [1]. [1] http://gcc.gnu.org/install/build.html Okay, I stand corrected. Regards, Bob Young * -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On Wednesday 07 June 2006 21:50, Bob Young wrote: On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e Ugh, this is completely pointless. A single emerge -e world is sufficient. Depends on what you consider sufficient. Although what the page recommends was misquoted, it actually suggests: emerge -e system emerge -e system emerge -e world emerge -e world That's probably is a little bit excessive, but the reason for doing the two emerge -e systems is so that the new tool chain is built with the new tool chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler. What you actually want is a gcc-4.1.1 that was built with gcc-4.1.1. You could emerge the compiler twice before doing the emerge -e system, but the the emerges that happen before glibc is rebuilt are linked against a glibc that was built with the old compiler. Same with the rest of the tool chain and libraries. That being said emerge -e system is probably overkill just for a new toolchain. Updating a subset of all possible toolchain related things and then following that by a single emerge -e world would probably be sufficient for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html is about doing an install, but it shows how to update a subset of the entire tool chain. Note that the article does in the end, do a double emerge -e system, so the the value of updating a toolchain subset is questionable for the article's purposes. In short: emerge gcc-config glibc binutils libstdc++-v3 gcc emerge gcc-config glibc binutils libstdc++-v3 gcc emerge -e world To be clear, in order to make sure absolutely everything is updated and the libraries that are linked against are also updated prior to use, the two emerge -e system commands, are the definitive solution. For those who don't want to spend many extra hours of compile time, in order to gain a 0.5% increase in performance, the above is offered for consideration. Regards, Bob Young Wow! I said the same thing a week or so ago and got the same rebuttal. However, it's what I do none the less. And it works. -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] gcc-4.1.1
-Original Message- From: Jerry McBride [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 07, 2006 7:10 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 On Wednesday 07 June 2006 21:50, Bob Young wrote: Note that the article does in the end, do a double emerge -e system, so the the value of updating a toolchain subset is questionable for the article's purposes. In short: emerge gcc-config glibc binutils libstdc++-v3 gcc emerge gcc-config glibc binutils libstdc++-v3 gcc emerge -e world To be clear, in order to make sure absolutely everything is updated and the libraries that are linked against are also updated prior to use, the two emerge -e system commands, are the definitive solution. For those who don't want to spend many extra hours of compile time, in order to gain a 0.5% increase in performance, the above is offered for consideration. Regards, Bob Young Wow! I said the same thing a week or so ago and got the same rebuttal. However, it's what I do none the less. And it works. I've been thinking about this over the last week or so. In particular the fact that gcc always uses itself to build itself, does elminate the need for building gcc twice. That being the case, emerging the new gcc then selecting it as the default system compiler followed by a single emerge -e world should be all that is necessary. I suppose it's possible that a few apps or utilities that use static linking *could* possibly end up linking against libraries that have not been rebuilt with the new compiler yet due to build order issues. However since the number of apps and utilities that actually use static linking is very small, it doesn't seem that a double emerge -e world or system is justified. That being said, seems these two articles appear to be giving out bad information: http://forums.gentoo.org/viewtopic.php?t=282474highlight= http://forums.gentoo.org/viewtopic-t-345229.html If I've mis-characterisized the issue in the above description I'd appreciate it if someone would correct any mis-statements. Lastly, since the Gentoo handbook no longer describes a stage one install, is there any official documentation that describes the *correct* way to do a stage3 install and end up with the same level of optimization and customization that used to be provided by a stage1 install? -- Regards, Bob Young -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/12/06, Bob Young [EMAIL PROTECTED] wrote: That being said, seems these two articles appear to be giving out bad information: http://forums.gentoo.org/viewtopic.php?t=282474highlight= http://forums.gentoo.org/viewtopic-t-345229.html Yes, I would have to agree. The first is just so utterly wrong I can't actually read it all the way through. I also have problems with the second, aside from the gcc issues. It puts a lot of effort into fine-tuning hdparm settings, but misses the noatime option in fstab that actually makes a much bigger difference. And it recommends -nptlonly, without any reasoning why. Of course it is also marked as deprecated, with a link to the new version, but that requires some kind of login to access. But basically the forums, the wiki, and even this mail list are all buyer beware! They are all unofficial, and there is no quality control other that what is provided by other users. Heck, don't even trust me without doing some of your own research. I will sometimes mention whatever official sources support my position, but usually only if I am trying to make a particularly strong argument. If I make an unsupported assertion, you *should* question it! *I may not* actually know what I am talking about! appreciate it if someone would correct any mis-statements. Lastly, since the Gentoo handbook no longer describes a stage one install, is there any official documentation that describes the *correct* way to do a stage3 install and end up with the same level of optimization and customization that used to be provided by a stage1 install? The FAQ entry: http://www.gentoo.org/doc/en/faq.xml?style=printable#stage12 Note that although the faq is about installing from stage1 (or stage2), it really doesn't say how to install from stage1. It tells how to get to the same point from a stage3 install. There was a discussion about this on gentoo-dev late last year. While not 'official documentation', it is at least from people who should know what they are talking about: http://article.gmane.org/gmane.linux.gentoo.devel/33251/match=decision+remove+stage1+2 So the answer seems to be: 1. Install a stage3 as documented 2. [Edit and] run bootstrap.sh 3. emerge -e system -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On Thu, 2006-06-08 at 11:05 -0700, Richard Fish wrote: There is simply no way to build libstdc++-v3 with the new compiler; it would break any programs that need it. Gcc likes to make incompatible changes in the C++ ABI from one version to the next, so building -v3 with the new gcc would give you the old stdc++ library, but the new ABI, and your programs would be broken. This is one of the major reasons that gcc uses itself to build itself, to make sure that it's ABI is consistent. scarlatti ~ $ genlop libstdc++-v3 * sys-libs/libstdc++-v3 Wed Dec 21 10:45:38 2005 sys-libs/libstdc++-v3-3.3.4 Sun Mar 5 07:58:19 2006 sys-libs/libstdc++-v3-3.3.6 Sat Mar 18 13:23:43 2006 sys-libs/libstdc++-v3-3.3.6 Sun Apr 2 04:07:24 2006 sys-libs/libstdc++-v3-3.3.6 scarlatti ~ $ equery depends libstdc++-v3 [ Searching for packages depending on libstdc++-v3... ] sys-devel/gcc-3.4.6-r1 I definitely built libstdc++-v3 with gcc-4.1.1, but interestingly genlop doesn't report any USE or CFLAGS for it. Hmmm. scarlatti ~ $ genlop -i libstdc++-v3 * sys-libs/libstdc++-v3 Total builds: 4 Global build time: 59 minutes and 57 seconds. Average merge time: 14 minutes and 59 seconds. Info about currently installed ebuild: * sys-libs/libstdc++-v3-3.3.6 Install date: Sun Apr 2 04:07:24 2006 Anyway, I haven't had any problems, but maybe that's because no package I have uses libstdc++-v3. --- Vladimir Vladimir G. Ivanovic Palo Alto, CA 94306 +1 650 678 8014 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/9/06, Vladimir G. Ivanovic [EMAIL PROTECTED] wrote: I definitely built libstdc++-v3 with gcc-4.1.1, but interestingly genlop doesn't report any USE or CFLAGS for it. Hmmm. Look at the ebuild for libstdc++-v3. It actually builds gcc-3.3 with C++ support, and then pulls the libstdc++.so library out of that. As we've already discussed, gcc uses itself to build itself, so you actually built libstdc++-v3 with gcc-3.3. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
thanks every body, every thing goes fine now without errors i didn't change any thing just a reboot then etc-update; env-update and every thing works fine. On 6/8/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/7/06, Evan Klitzke [EMAIL PROTECTED] wrote: AFAIK, the only thing that you need to compile twice is GCC. And you don't even really need to do that twice. The second pass will may pass on new optimizations that will make it more efficient, but the code it outputs will be exactly the same. You are correct that gcc's output will be the same, but you don't need to merge it twice because gcc uses itself to build itself. It uses a 3-stage bootstrap, where it uses the system compiler to build an initial version of itself, then uses that version to rebuild itself. Then for good measure, it then uses that version to build the final version of itself. The final result is completely independant of the original compiler. -Richard -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] gcc-4.1.1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Richard Fish Sent: Wednesday, June 07, 2006 9:24 PM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 On 6/7/06, Bob Young [EMAIL PROTECTED] wrote: chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler. This is false. Gcc uses itself to build itself. It uses the system compiler to build an initial version of itself, and then uses that version to build itself. And then for good measure, it uses that version to build the final version. It's called a 3-stage bootstrap, and is documented in the file INSTALL/build.html in the gcc sources. You can also look at /usr/portage/eclass/toolchain.eclass to determine that Gentoo uses the bootstrap-lean target by default. No, sorry that's just wrong. gcc is slotted, if the above were true there would be no need for gcc-config in order to select a default compiler. When a new compiler is emerged, it does *not* automatically become the default system compiler, it must be selected, and that can only happen after it has successfully been emerged. The first time a new gcc compiler is emerged, it is indeed built with the previous version of the compiler that is currently istalled as the system default. Frankly, anybody who claims that gcc needs to be merged twice so it can be built with itself and produce better object code does not have a clue what they are talking about and you should simply disregard anything else they have to say about what is necessary/useful when upgrading gcc. It does have to be emerged twice in order for it to be built with itself, anybody who thinks otherwise doesn't understand the basic principles of compiling and linking. happen before glibc is rebuilt are linked against a glibc that was built with the old compiler. And guess what difference this makes to the end result. None. Nada. Nothing. Because for basically every program on your system, they are *dynamically linked* against glibc. Are you absolutely 100% sure that every single system utility and application is *dynamically* linked, and that no apps or utilities anywhere in the system specifies *static* linking? There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Really, so people who intentionally and specifically want to upgrade absolutely *everything* should not worry about what gets left out because Richard says it's unimportant? The issue is about upgrading gcc and even the gcc upgrade howto recommends an emerge -e world. It's clear that gcc it self at least has to be emerged twice in order to build the new gcc *with* the new gcc. Whether this is strictly necessary or not is certaintly debatable, but since it executes fairly quickly, and seems a prudent step, I'd argue that it's a reasonable course. Of course a selecting the new gcc as the default with gcc-config is also required in between, but that's self evident. Adding gcc-config, glibc, binutils, libstdc++-v3, quickly covers the most important parts of the basic tool chain, and covers most utilities or apps that might specify static linking, and executes much much faster than an emerge -e system. There is no value to having glibc or libstdc++-v3 in the first line. There is no value at all to doing that twice. Twice is the only way to build the new gcc *with* the new gcc. I should have added the gcc-config select command in between, but I thought that was pretty clearly necessary. Also, libstdc++-v3 is only needed by a few binary-only programs on Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I already said uses itself to build itself, so I cannot see any point in ever re-merging libstdc++-v3 due to a gcc upgrade I know you said it, but that doesn't mean you were correct. The fact is that anything emerged is built with the currently selected system compiler, the first time a new compiler is emerged it is built with the current (old) compiler (duh). *After* it is successfuly emerged, it can be selected as the default system compiler, then re-emergeing gcc will result in the new compiler being built with the new compiler. The same holds true for libstdc++-v3 orginally it was built with the default system compiler, it makes sense to have it rebuilt with the new compiler. Regards, Bob Young -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Hi, On Thu, 8 Jun 2006 05:34:49 -0700 Bob Young [EMAIL PROTECTED] wrote: No, sorry that's just wrong. gcc is slotted, if the above were true there would be no need for gcc-config in order to select a default compiler. Did you follow the documentation pointer given in the mail you are replying to before making such statements? In fact, you're wrong here. When a new compiler is emerged, it does *not* automatically become the default system compiler, it must be selected, and that can only happen after it has successfully been emerged. The first time a new gcc compiler is emerged, it is indeed built with the previous version of the compiler that is currently istalled as the system default. You haven't understood a word from the posting you're replying to. It does have to be emerged twice in order for it to be built with itself, anybody who thinks otherwise doesn't understand the basic principles of compiling and linking. Try to understand what you are replying to. GCC's internal build logic does the staging. That's got nothing to do with what your system calls when you issue gcc, and only at that point the slotting of GCC versions comes into play. Because for basically every program on your system, they are *dynamically linked* against glibc. Are you absolutely 100% sure that every single system utility and application is *dynamically* linked, and that no apps or utilities anywhere in the system specifies *static* linking? What would that change? We're talking about GCC, not glibc. There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Really, so people who intentionally and specifically want to upgrade absolutely *everything* should not worry about what gets left out because Richard says it's unimportant? If the build logic of those programs uses glibc statically, the specific ebuilds for such programs have to get updated in order to incorporate fixes that are needed in statically compiled libraries. Following *your* logic, one would have to do emerge -e world after the slightest update just for the case that the updated package is compiled statically into something. The issue is about upgrading gcc and even the gcc upgrade howto recommends an emerge -e world. It's clear that gcc it self at least has to be emerged twice in order to build the new gcc *with* the new gcc. Repeating this doesn't make it more true than being plain wrong. There is no value to having glibc or libstdc++-v3 in the first line. There is no value at all to doing that twice. Twice is the only way to build the new gcc *with* the new gcc. I should have added the gcc-config select command in between, but I thought that was pretty clearly necessary. He was talking about glibc at that point. I don't see no value either. Also, libstdc++-v3 is only needed by a few binary-only programs on Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I already said uses itself to build itself, so I cannot see any point in ever re-merging libstdc++-v3 due to a gcc upgrade The same holds true for libstdc++-v3 orginally it was built with the default system compiler, it makes sense to have it rebuilt with the new compiler. Not sure here, but it may well be possible that the ebuild in question builds a gcc 3.3 for bootstrapping this, too. -hwh -- gentoo-user@gentoo.org mailing list
RE: [gentoo-user] gcc-4.1.1
-Original Message- From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 6:32 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 You haven't understood a word from the posting you're replying to. It does have to be emerged twice in order for it to be built with itself, anybody who thinks otherwise doesn't understand the basic principles of compiling and linking. Try to understand what you are replying to. GCC's internal build logic does the staging. That's got nothing to do with what your system calls when you issue gcc, and only at that point the slotting of GCC versions comes into play. Show me some documentation for this staging you refer to. When you emerge gcc it is built with the current compiler, if the current compiler is gcc 3.4.6, and you emerge gcc 4.1.1, that means that while gcc 4.1.1 is being emerged it is built with gcc 3.4.6. gcc 4.1.1 can't be built with 4.1.1 because it hasn't been emerged yet, and as far as the system knows it doesn't actually exist yet. Can you clearly and concisely explain to me how something that is in the process of being emerged can be used to emerge itself? Doesn't make sense. Regards, Bob Young -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Thursday 08 June 2006 16:00 skrev Bob Young: Show me some documentation for this staging you refer to. If you unpack the gcc sources you will find it in gcc-*/INSTALL/build.html as already mentioned by Richard. But you can also see it at [1]. [1] http://gcc.gnu.org/install/build.html -- Bo Andresen pgpuriDC0R7l1.pgp Description: PGP signature
RE: [gentoo-user] gcc-4.1.1
-Original Message- From: Bo Ørsted Andresen [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 7:29 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 Thursday 08 June 2006 16:00 skrev Bob Young: Show me some documentation for this staging you refer to. If you unpack the gcc sources you will find it in gcc-*/INSTALL/build.html as already mentioned by Richard. But you can also see it at [1]. [1] http://gcc.gnu.org/install/build.html Okay, I stand corrected. Regards, Bob Young -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On Thu, Jun 08, 2006 at 07:00:22AM -0700, Bob Young wrote: From: Hans-Werner Hilse [mailto:[EMAIL PROTECTED] Sent: Thursday, June 08, 2006 6:32 AM To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] gcc-4.1.1 Try to understand what you are replying to. GCC's internal build logic does the staging. That's got nothing to do with what your system calls when you issue gcc, and only at that point the slotting of GCC versions comes into play. Show me some documentation for this staging you refer to. He did! In the INSTALL/build.html file in the gcc sources. When you emerge gcc it is built with the current compiler, if the current compiler is gcc 3.4.6, and you emerge gcc 4.1.1, that means that while gcc 4.1.1 is being emerged it is built with gcc 3.4.6. gcc 4.1.1 can't be built with 4.1.1 because it hasn't been emerged yet, and as far as the system knows it doesn't actually exist yet. Yes. The *first* time that gcc 4.1.1 is built. But then the gcc build process builds it a *second* time, using the gcc 4.1.1 it's just built. And for good measure, it goes on to build it a *third* time with the second version it produced. This is all done by the gcc build process (it's in the Makefile), which is what emerge runs. Can you clearly and concisely explain to me how something that is in the process of being emerged can be used to emerge itself? Doesn't make sense. You're obviously right that you have to *compile* a new gcc at least twice. But this is done automatically by the gcc build process, so there's no need to build (or emerge) gcc twice. This has nothing to do with gentoo. Downloading the gcc sources manually and running ./configure, make, make install (or whatever the exact gcc build process is) would work too: you'd only need to do it once. Toby -- PhD Student Quantum Information Theory group Max Planck Institute for Quantum Optics Garching, Germany email: [EMAIL PROTECTED] web: www.dr-qubit.org -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Others have already coverd the major points, so just a couple of things to add... On 6/8/06, Bob Young [EMAIL PROTECTED] wrote: Are you absolutely 100% sure that every single system utility and application is *dynamically* linked, and that no apps or utilities anywhere in the system specifies *static* linking? I didn't say every single system utility and application. I said basically every program, which was a bad way of saying almost all, since it might not be obvious for non-native english speakers (and even some native english speakers). There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Really, so people who intentionally and specifically want to upgrade absolutely *everything* should not worry about what gets left out because Richard says it's unimportant? No. They should follow the gcc upgrade guide that says emerge -e system followed by emerge -e world. BTW, I was incorrect when I stated only for system recover purposes. The static programs do include things like busybox (which doesn't use glibc at all AFAIK), nash, and insmod.static, which are /mostly/ useful for system recovery. But it also includes things that have to run before the root filesystem is mounted, like splash and suspend utilities. I still think anybody worried about the performance of (e.g.) lvm is a bit crazy, but if they want to remerge it after remerging glibc to get the new optimized code, well, so be it... The same holds true for libstdc++-v3 orginally it was built with the default system compiler, it makes sense to have it rebuilt with the new compiler. There is simply no way to build libstdc++-v3 with the new compiler; it would break any programs that need it. Gcc likes to make incompatible changes in the C++ ABI from one version to the next, so building -v3 with the new gcc would give you the old stdc++ library, but the new ABI, and your programs would be broken. This is one of the major reasons that gcc uses itself to build itself, to make sure that it's ABI is consistent. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
any one here know any thing about these problems ?? after emerge -e world everything is working fine. -- Best Regards, Peper -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
I use many software from gnome/kde/... and no problemsOn 6/7/06, Peper [EMAIL PROTECTED] wrote: any one here know any thing about these problems ??after emerge -e world everything is working fine.--Best Regards,Peper--gentoo-user@gentoo.org mailing list-- Julien Cabillot
Re: [gentoo-user] gcc-4.1.1
Mohammed Hagag wrote: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. any one here know any thing about these problems ?? It works fine here. A few packages (mostly GNUstep ones) fails to compile with GCC-4.1.1 (at least with my configuration), but we are talking very few packages. Just remember to do 'emerge -e system emerge -e world' and you'll be fine. -Herkild -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On Wed, 7 Jun 2006 16:53:31 +0300, Mohammed Hagag wrote: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. What problems? i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. What error? any one here know any thing about these problems ?? That is difficult because you haven't actually told us anything about the problems you are having. If you give exact details of what you are doing and the error messages you receive, someone should be able to give useful advice. -- Neil Bothwick What's another word for `Thesaurus'? signature.asc Description: PGP signature
Re: [gentoo-user] gcc-4.1.1
Wednesday 07 June 2006 15:53 skrev Mohammed Hagag: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? I had to run 'fix_libtool_files.sh 3.3.6' (my previous gcc was v. 3.3.6). I did not have to emerge -e world (at least not yet). I have compiled qt, all of kde and some other apps that has been upgraded in ~x86 Gentoo during the last 12 days with gcc 4.1.1. I have not yet compiled glibc and glib with gcc 4.1.1. I have yet to see a problem that can't be solved by recompiling something. :) i have some problems with xf86 video drivers and some other ebuilds. I you want help you have to be a lot more specific. What xf86 video drivers? i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. Which important packages? What are the errors? any one here know any thing about these problems ?? Given the very limited info you have provided, I very much doubt it.. -- Bo Andresen pgpgt59WFzh6X.pgp Description: PGP signature
RE: [gentoo-user] gcc-4.1.1
Did it without any problem. -Message d'origine- De : Mohammed Hagag [mailto:[EMAIL PROTECTED] Envoyé : mercredi 7 juin 2006 15:54 À : gentoo-user@lists.gentoo.org Objet : [gentoo-user] gcc-4.1.1 i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. any one here know any thing about these problems ?? -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Mohammed Hagag wrote: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. any one here know any thing about these problems ?? I did: emerge -s emerge -e revdep-rebuild You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e to make sure the toolchain is built correctly. HTH, Roy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
I had some weird problems with the emerge -e system (libraries not being properly identified to ./config scripts, that blocking issue with pam.d shadow, usual unstable tree stuff), but after toying with it for a few hours, I have a successfully running desktop. On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: Mohammed Hagag wrote: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. any one here know any thing about these problems ?? I did: emerge -s emerge -e revdep-rebuild You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e to make sure the toolchain is built correctly. HTH, Roy -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/7/06, Mike Huber [EMAIL PROTECTED] wrote: I had some weird problems with the emerge -e system (libraries not being properly identified to ./config scripts, that blocking issue with pam.d shadow, usual unstable tree stuff), but after toying with it for a few hours, I have a successfully running desktop. On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: Mohammed Hagag wrote: i just want to know if any one here have built a full desktop with gcc-4.1.1 without problems ? i have some problems with xf86 video drivers and some other ebuilds. i did a bootstartp from normal stage3 and i'm doing emerge -e world now but some important packages did not compile most of the with errors about glibc include files. any one here know any thing about these problems ?? I did: emerge -s emerge -e revdep-rebuild You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e to make sure the toolchain is built correctly. I'm watching this topic with curiosity, I have switched to ~x86 recently and after it all (and a few debugging) I have all my packages testing now, but have not switched to the new GCC for fear of things breaking beyound my knowledge on how to fix it. So, if people start replying saying things are stable with the new GCC I might switch to it completely and wait a few days before the emerge -e system emerge -e world completes. Right now I really need my notebook, so, I'm not even thinking about such a complex and time consuming operation. -- Daniel da Veiga Computer Operator - RS - Brazil -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V- PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++ --END GEEK CODE BLOCK-- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
The pam-login/shadow blocking issue was a portage specific thing -- you would have gotten it no matter what version of gcc you were running. In this case it was because pam-login being deprecated. On 6/7/06, Mike Huber [EMAIL PROTECTED] wrote: I had some weird problems with the emerge -e system (libraries not being properly identified to ./config scripts, that blocking issue with pam.d shadow, usual unstable tree stuff), but after toying with it for a few hours, I have a successfully running desktop. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
Daniel da Veiga wrote: I'm watching this topic with curiosity, I have switched to ~x86 recently and after it all (and a few debugging) I have all my packages testing now, but have not switched to the new GCC for fear of things breaking beyound my knowledge on how to fix it. So, if people start replying saying things are stable with the new GCC I might switch to it completely and wait a few days before the emerge -e system emerge -e world completes. I was running stable with a lot of testing unmasked. Then upgraded to gcc-4.1.1 with an immediate emerge -s emerge -e, which went mostly smooth. Then decided to go ~x86 for the system. That is where the pain was, particularly expat which caused most of kde/gnome to need to be upgraded. Unfortunately a lot of the tools to do the rebuild also depended on expat. So it was update a few packages, rebuild a tool, update a few more packages, ... Lesson learned is when upgrading to expat-2, immediately take the hours needed to do the revdep-rebuild (in all honesty, I didn't see the ewarn message because I was upgrading 448 packages). It really would have been nice if the expat-2 emerge package died after giving the instructions to revdep-rebuild... So far (5 days) the system has been real nice, no problems. KDE appears (subjective) faster (with USE=kdehiddenvisibility). So +1 on upgrading a ~x86 to gcc-4.1.1. For those considering stable to testing, the main changes are pam-logon/shadow (unmerge pam-logon), coldplug/udev (unmerge coldplug), expat (revdep-rebuild), ocaml (dependent packages must be manually rebuilt afterwards). HTH, Roy -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: Daniel da Veiga wrote: I'm watching this topic with curiosity, I have switched to ~x86 recently and after it all (and a few debugging) I have all my packages testing now, but have not switched to the new GCC for fear of things breaking beyound my knowledge on how to fix it. So, if people start replying saying things are stable with the new GCC I might switch to it completely and wait a few days before the emerge -e system emerge -e world completes. I was running stable with a lot of testing unmasked. Then upgraded to gcc-4.1.1 with an immediate emerge -s emerge -e, which went mostly smooth. Then decided to go ~x86 for the system. That is where the pain was, particularly expat which caused most of kde/gnome to need to be upgraded. Unfortunately a lot of the tools to do the rebuild also depended on expat. So it was update a few packages, rebuild a tool, update a few more packages, ... Lesson learned is when upgrading to expat-2, immediately take the hours needed to do the revdep-rebuild (in all honesty, I didn't see the ewarn message because I was upgrading 448 packages). It really would have been nice if the expat-2 emerge package died after giving the instructions to revdep-rebuild... So far (5 days) the system has been real nice, no problems. KDE appears (subjective) faster (with USE=kdehiddenvisibility). So +1 on upgrading a ~x86 to gcc-4.1.1. For those considering stable to testing, the main changes are pam-logon/shadow (unmerge pam-logon), coldplug/udev (unmerge coldplug), expat (revdep-rebuild), ocaml (dependent packages must be manually rebuilt afterwards). That is some precious info. I'll remember that when switching next week, thanks. I will not have much problems with dependencies/blocks and stuff because I already switched the whole tree to ~x86, masking some blocks, so, now it is just a matter of recompiling stuff. Anyway, If I switch, do the emerge -e system and world and eventually stop, nothing will (in theory) be broken as long as I mantain compatibility libraries right? I'll switch from 3.4.5 to 4.1, dunno if there were substancial changes like when switching from 3.3 to 3.4. Anyway, gotta read the gcc upgrade guide again. -- Daniel da Veiga Computer Operator - RS - Brazil -BEGIN GEEK CODE BLOCK- Version: 3.1 GCM/IT/P/O d-? s:- a? C++$ UBLA++ P+ L++ E--- W+++$ N o+ K- w O M- V- PS PE Y PGP- t+ 5 X+++ R+* tv b+ DI+++ D+ G+ e h+ r+ y++ --END GEEK CODE BLOCK-- -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e Ugh, this is completely pointless. A single emerge -e world is sufficient. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
AFAIK, the only thing that you need to compile twice is GCC. And you don't even really need to do that twice. The second pass will may pass on new optimizations that will make it more efficient, but the code it outputs will be exactly the same. -- Evan Klitzke On 6/7/06, Richard Fish [EMAIL PROTECTED] wrote: On 6/7/06, Roy Wright [EMAIL PROTECTED] wrote: You might want to read: http://forums.gentoo.org/viewtopic.php?t=282474highlight= which basically recommends: emerge -s emerge -s emerge -e emerge -e Ugh, this is completely pointless. A single emerge -e world is sufficient. -Richard -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/7/06, Bob Young [EMAIL PROTECTED] wrote: chain. At the end of the first emerge -e system you may have a new compiler, but that new compiler was built with the old compiler. This is false. Gcc uses itself to build itself. It uses the system compiler to build an initial version of itself, and then uses that version to build itself. And then for good measure, it uses that version to build the final version. It's called a 3-stage bootstrap, and is documented in the file INSTALL/build.html in the gcc sources. You can also look at /usr/portage/eclass/toolchain.eclass to determine that Gentoo uses the bootstrap-lean target by default. Frankly, anybody who claims that gcc needs to be merged twice so it can be built with itself and produce better object code does not have a clue what they are talking about and you should simply disregard anything else they have to say about what is necessary/useful when upgrading gcc. happen before glibc is rebuilt are linked against a glibc that was built with the old compiler. And guess what difference this makes to the end result. None. Nada. Nothing. Because for basically every program on your system, they are *dynamically linked* against glibc. This means that you can recompile glibc with different CFLAGS, a different compiler version, whatever, and they will *never notice*. Well, unless you use broken CFLAGS or a broken compiler, but no amount of emerge -e world can help you then. There are a few statically linked programs that will include glibc internally. These are used only for system recovery purposes...there is no need to worry about them at all. Again, *anybody* who claims that the end result of a compile depends upon what version of glibc you have installed, much less what CFLAGS or compiler glibc was built with, does not know what they are talking about. for most people. This page: http://forums.gentoo.org/viewtopic-t-345229.html is about doing an install, but it shows how to update a subset of the entire tool chain. Note that the article does in the end, do a double emerge -e system, so the the value of updating a toolchain subset is questionable for the article's purposes. Any article, on the forums or anywhere else, that claims some speed benefit resulting from doing emerge -e world twice is wrong. In short: emerge gcc-config glibc binutils libstdc++-v3 gcc emerge gcc-config glibc binutils libstdc++-v3 gcc emerge -e world There is no value to having glibc or libstdc++-v3 in the first line. There is no value at all to doing that twice. Also, libstdc++-v3 is only needed by a few binary-only programs on Gentoo. Moreover, it is simply a build of gcc-3.3.6, which as I already said uses itself to build itself, so I cannot see any point in ever re-merging libstdc++-v3 due to a gcc upgrade, much less doing that 3 or 4 times! To be clear, in order to make sure absolutely everything is updated and the libraries that are linked against are also updated prior to use, the two emerge -e system commands, are the definitive solution. For those who don't want to spend many extra hours of compile time, in order to gain a 0.5% increase in performance, the above is offered for consideration. No, there will not even be a 0.5% increase in performance. Not even 0.1%. Not even 0.0.01%. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] gcc-4.1.1
On 6/7/06, Evan Klitzke [EMAIL PROTECTED] wrote: AFAIK, the only thing that you need to compile twice is GCC. And you don't even really need to do that twice. The second pass will may pass on new optimizations that will make it more efficient, but the code it outputs will be exactly the same. You are correct that gcc's output will be the same, but you don't need to merge it twice because gcc uses itself to build itself. It uses a 3-stage bootstrap, where it uses the system compiler to build an initial version of itself, then uses that version to rebuild itself. Then for good measure, it then uses that version to build the final version of itself. The final result is completely independant of the original compiler. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 unable to compile kdelibs due to missing libstdc++
And still I get this. Any ideas? I have run into many strange problems with confcache, have you flushed(just remove /var/tmp/confcache) it after upgrade to 4.1.1? -- Best Regards, Peper -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 unable to compile kdelibs due to missing libstdc++
On 02/06/06, Peper [EMAIL PROTECTED] wrote: And still I get this. Any ideas? I have run into many strange problems with confcache, have you flushed(just remove /var/tmp/confcache) it after upgrade to 4.1.1? I can't even find that file in my system. :-( -- Best Regards, Peper -- gentoo-user@gentoo.org mailing list -- Paulo Jorge Matos - pocm at sat inesc-id pt Web: http://sat.inesc-id.pt/~pocm Computer and Software Engineering INESC-ID - SAT Group -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
JimD wrote: Jason Weisberger wrote: List, I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. So far I've had just about every problem under the sun, mostly in the form of filesize errors which I wouldn't think would be related to GCC, but then again: app-admin/perl-cleaner x11-proto/xextproto x11-proto/xcmiscproto-1.1.2 I had this same issue with app-admin/perl-cleaner. I think there is a bad tarball on some of the mirrors. I grabbed this one: http://www.gtlib.gatech.edu/pub/gentoo/distfiles/perl-cleaner-1.03.tar.gz and saved it to /usr/portage/distfiles and then ran this (one line): ebuild /usr/portage/app-admin/perl-cleaner/perl-cleaner-1.03.ebuild digest Now it merged in fine. Jim Well, I'm using GCC-3.4.5 and I had the same problem with app-admin/perl-cleaner. It's not GCC-related, and it's not exactly the first time we've had to make our own digests ;) Kristian Poul Herkild -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On 5/28/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: this security measure. In this case the tar file changed without changing the name after you originally installed the package (or after it was downloaded to the mirror that you are using...). This change could be a bugfix. By making your own digest you don't get this bugfix... I just have to say that if upstream authors include a bug-fix without releasing a new version (and a differently named tarball), they need a good clubbing. I can see a reason to release the same version of software with a documentation update (readme, authors, known issues, faq, etc), which would cause a different tarball with the same name. But if any of the sources change, I feel that should *always* be a new version. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Sunday 28 May 2006 21:26 skrev Richard Fish: I just have to say that if upstream authors include a bug-fix without releasing a new version (and a differently named tarball), they need a good clubbing. I agree with that. Still, apparently that is what happened here. It's stupid, but since the devs did change the manifest, I at least want the version that fits the manifest. -- Bo Andresen pgpkVJ5dzwmO7.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
On Sunday 28 May 2006 19:54, Bo Ørsted Andresen wrote: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. At least in my case this bug showed when I upgraded from perl-cleaner-1.03 to perl-cleaner-1.03-r1. Those two ebuilds are identical and use the same tar file as source. This means that when I originally (a couple of weeks ago) installed 1.03 the digest fitted the other, smaller tar file, which means that devs has approved both versions of that tar file). It did install successfully (and seemed to work) so it couldn't be too corrupted. So while it is possible that the devs approved a file that shouldn't have been approved, I prefer to think that upstream just did something stupid by upgrading the package without a revision bump.. :) -- Bo Andresen pgp13EeZEtVTX.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 00:10, Bo Ørsted Andresen wrote: Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. because I know at least one mirror which regularly corrupts files. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Monday 29 May 2006 00:32 skrev Hemmann, Volker Armin: While that is possible I'm not really sure why you consider it more likely. because I know at least one mirror which regularly corrupts files. The digest still changed so it would have to be a mirror that the devs who created the digests used.. -- Bo Andresen pgpyaZtT4dwjS.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
Hemmann, Volker Armin wrote: On Monday 29 May 2006 00:10, Bo Ørsted Andresen wrote: Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. because I know at least one mirror which regularly corrupts files. Don't use that one. LOL Which is it so the rest of us can avoid it? Why ask for problems when we have enough already. ;-) Dale :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 00:41, Bo Ørsted Andresen wrote: Monday 29 May 2006 00:32 skrev Hemmann, Volker Armin: While that is possible I'm not really sure why you consider it more likely. because I know at least one mirror which regularly corrupts files. The digest still changed so it would have to be a mirror that the devs who created the digests used.. what? I am talking about the problem, that mirrors might corrupt files and that this is why making a new digest may not be a good idea. Also, it might be possible, that someone hacked the file on the mirror. And what are you talking about? *confused* -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 00:43, Teresa and Dale wrote: Hemmann, Volker Armin wrote: On Monday 29 May 2006 00:10, Bo Ørsted Andresen wrote: Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. because I know at least one mirror which regularly corrupts files. Don't use that one. LOL Which is it so the rest of us can avoid it? Why ask for problems when we have enough already. ;-) I am using it becaue I am only allowed to download a certain volume per month and downloading from that mirror is 'free' for me - the traffic to and from that one does not add up onto my free traffic. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Hemmann, Volker Armin wrote: On Monday 29 May 2006 00:43, Teresa and Dale wrote: Don't use that one. LOL Which is it so the rest of us can avoid it? Why ask for problems when we have enough already. ;-) I am using it becaue I am only allowed to download a certain volume per month and downloading from that mirror is 'free' for me - the traffic to and from that one does not add up onto my free traffic. Well, if they corrupt things, I can see why they are free. That really sucks but I guess you are stuck with crossing your fingers and hoping it will be a good file. Dale :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Monday 29 May 2006 00:51 skrev Hemmann, Volker Armin: The digest still changed so it would have to be a mirror that the devs who created the digests used.. what? I am talking about the problem, that mirrors might corrupt files and that this is why making a new digest may not be a good idea. Also, it might be possible, that someone hacked the file on the mirror. And what are you talking about? *confused* Like I stated in my previous mail I installed this a couple of weeks ago with the older, smaller version of the tar file. At that time there was no digest verification error which means that the digest fitted that tar file. When I reinstalled yesterday (after the ebuild had been bumped to -r1) but with the name of the tar file unchanged I ran into a digest verification error because the digest had changed to fit the newer, bigger tar file with the same name. Since the name was unchanged I had to delete the file to have the newer version downloaded which fitted the new digest... Note that the ebuilds of 1.03 and 1.03-r1 are identical. You get exactly the same software no matter which one of them you install. But since the tar file has changed you do not get the same as 2 weeks ago when I originally installed 1.03. I have exactly run a diff on those tar files so I can't tell if the difference is important... Please read the previous mail I sent 75 minutes ago. I hope I am more clear now.. -- Bo Andresen pgpyP9uqGeNV8.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
Monday 29 May 2006 01:11 skrev Teresa and Dale: Well, if they corrupt things, I can see why they are free. That really sucks but I guess you are stuck with crossing your fingers and hoping it will be a good file. Well, that's what the digest verification is for, right. It ensures that he will know if a file is (or may be) corrupted... :) -- Bo Andresen pgpA2fMN296Kp.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
Bo Ørsted Andresen wrote: Monday 29 May 2006 01:11 skrev Teresa and Dale: Well, if they corrupt things, I can see why they are free. That really sucks but I guess you are stuck with crossing your fingers and hoping it will be a good file. Well, that's what the digest verification is for, right. It ensures that he will know if a file is (or may be) corrupted... :) It's just a shame that he has to use that one or pay extra to get a good mirror so he doesn't have to worry about it to begin with. At least this makes it harder for the hackers to get us though. Dale :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 01:25, Bo Ørsted Andresen wrote: Monday 29 May 2006 00:51 skrev Hemmann, Volker Armin: The digest still changed so it would have to be a mirror that the devs who created the digests used.. what? I am talking about the problem, that mirrors might corrupt files and that this is why making a new digest may not be a good idea. Also, it might be possible, that someone hacked the file on the mirror. And what are you talking about? *confused* Like I stated in my previous mail I installed this a couple of weeks ago with the older, smaller version of the tar file. At that time there was no digest verification error which means that the digest fitted that tar file. When I reinstalled yesterday (after the ebuild had been bumped to -r1) but with the name of the tar file unchanged I ran into a digest verification error because the digest had changed to fit the newer, bigger tar file with the same name. Since the name was unchanged I had to delete the file to have the newer version downloaded which fitted the new digest... Note that the ebuilds of 1.03 and 1.03-r1 are identical. You get exactly the same software no matter which one of them you install. But since the tar file has changed you do not get the same as 2 weeks ago when I originally installed 1.03. I have exactly run a diff on those tar files so I can't tell if the difference is important... Please read the previous mail I sent 75 minutes ago. I hope I am more clear now.. yes you are -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 01:11, Teresa and Dale wrote: Hemmann, Volker Armin wrote: On Monday 29 May 2006 00:43, Teresa and Dale wrote: Don't use that one. LOL Which is it so the rest of us can avoid it? Why ask for problems when we have enough already. ;-) I am using it becaue I am only allowed to download a certain volume per month and downloading from that mirror is 'free' for me - the traffic to and from that one does not add up onto my free traffic. Well, if they corrupt things, I can see why they are free. That really sucks but I guess you are stuck with crossing your fingers and hoping it will be a good file. it happens one time a month or so. And they aren't 'Free' because the ftp server runs out of disk space once in a while (which is the reason for the corruption most of the times, or there was a cutted line again, or one of the routing facilities (Göttingen) we depend upon, has problems again), but because the ftp-server is part of our university network. And everything transfered in the internal network is free. And that is why digests are a good thing. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Hemmann, Volker Armin wrote: On Monday 29 May 2006 01:11, Teresa and Dale wrote: Hemmann, Volker Armin wrote: On Monday 29 May 2006 00:43, Teresa and Dale wrote: Don't use that one. LOL Which is it so the rest of us can avoid it? Why ask for problems when we have enough already. ;-) I am using it becaue I am only allowed to download a certain volume per month and downloading from that mirror is 'free' for me - the traffic to and from that one does not add up onto my free traffic. Well, if they corrupt things, I can see why they are free. That really sucks but I guess you are stuck with crossing your fingers and hoping it will be a good file. it happens one time a month or so. And they aren't 'Free' because the ftp server runs out of disk space once in a while (which is the reason for the corruption most of the times, or there was a cutted line again, or one of the routing facilities (Göttingen) we depend upon, has problems again), but because the ftp-server is part of our university network. And everything transfered in the internal network is free. And that is why digests are a good thing. Now I see. At least you knew something was wrong and got it corrected. Dale :-) -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
quit fucking email bombing me you ass holes. From:Bo Ørsted Andresen [EMAIL PROTECTED]Reply-To:gentoo-user@lists.gentoo.orgTo:gentoo-user@lists.gentoo.orgSubject:Re: [gentoo-user] GCC 4.1.1 ProblemsDate:Mon, 29 May 2006 00:10:25 +0200MIME-Version:1.0Received:from robin.gentoo.org ([140.105.134.102]) by bay0-mc2-f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 May 2006 15:14:51 -0700Received:from robin.gentoo.org (localhost [127.0.0.1])by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4SMD7KS003610;Sun, 28 May 2006 22:13:07 GMTReceived:from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53])by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4SMALei017832for gentoo-user@lists.gentoo.org; Sun, 28 May 2006 22:10:21 GMTReceived:from user2.cybercity.dk (user2.cybercity.dk [212.242.41.35])by cicero2.cybercity.dk (Postfix) with ESMTP id C1DA9244F08for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST)Received:from BA.zlin.dk (port78.ds1-abs.adsl.cybercity.dk [212.242.227.17])by user2.cybercity.dk (Postfix) with ESMTP id 6BB172869D7for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST)Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package.While that is possible I'm not really sure why you consider it more likely.At least in my case this bug showed when I upgraded from perl-cleaner-1.03 toperl-cleaner-1.03-r1. Those two ebuilds are identical and use the same tarfile as source. This means that when I originally (a couple of weeks ago)installed 1.03 the digest fitted the other, smaller tar file, which meansthat devs has approved both versions of that tar file). It did installsuccessfully (and seemed to work) so it couldn't be too corrupted.So while it is possible that the devs approved a file that shouldn't have beenapproved, I prefer to think that upstream just did something stupid byupgrading the package without a revision bump.. :)--Bo Andresen attach3 Join the new Messenger beta now -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Monday 29 May 2006 03:03, John Laremore wrote: quit fucking email bombing me you ass holes. stop insulting people stop sending html mail Nobody is bombing you - why did you suscribe to this mailing list, if you don't want emails from it? -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
First time I ever did this on a mailing list... John Laremore... you are PLONKED... My email filter now drops your emails into the bit bucket where they belong On Sunday 28 May 2006 21:03, John Laremore wrote: quit fucking email bombing me you ass holes. From: Bo ظrsted Andresen [EMAIL PROTECTED] Reply-To:[EMAIL PROTECTED] To:[EMAIL PROTECTED] Subject: Re: [gentoo-user] GCC 4.1.1 Problems Date: Mon, 29 May 2006 00:10:25 +0200 MIME-Version: 1.0 Received: from robin.gentoo.org ([140.105.134.102]) by bay0-mc2-f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 May 2006 15:14:51 -0700 Received: from robin.gentoo.org (localhost [127.0.0.1])by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4SMD7KS003610;Sun, 28 May 2006 22:13:07 GMT Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53])by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4SMALei017832for gentoo-user@lists.gentoo.org; Sun, 28 May 2006 22:10:21 GMT Received: from user2.cybercity.dk (user2.cybercity.dk [212.242.41.35])by cicero2.cybercity.dk (Postfix) with ESMTP id C1DA9244F08for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST) Received: from BA.zlin.dk (port78.ds1-abs.adsl.cybercity.dk [212.242.227.17])by user2.cybercity.dk (Postfix) with ESMTP id 6BB172869D7for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST) Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. At least in my case this bug showed when I upgraded from perl-cleaner-1.03 to perl-cleaner-1.03-r1. Those two ebuilds are identical and use the same tar file as source. This means that when I originally (a couple of weeks ago) installed 1.03 the digest fitted the other, smaller tar file, which means that devs has approved both versions of that tar file). It did install successfully (and seemed to work) so it couldn't be too corrupted. So while it is possible that the devs approved a file that shouldn't have been approved, I prefer to think that upstream just did something stupid by upgrading the package without a revision bump.. :) -- Bo Andresen attach3 Join the new Messenger beta now -- gentoo-user@gentoo.org mailing list -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
No problem, send a message to [EMAIL PROTECTED] and you'll recieve them no longer. You are aware that you had to sign up in the first place though... right? On Mon, 29 May 2006, John Laremore wrote: quit f'in email bombing me you arse holes. From: Bo ?rsted Andresen [EMAIL PROTECTED] Reply-To: gentoo-user@lists.gentoo.org To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] GCC 4.1.1 Problems Date: Mon, 29 May 2006 00:10:25 +0200 MIME-Version: 1.0 Received: from robin.gentoo.org ([140.105.134.102]) by bay0-mc2-f10.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 28 May 2006 15:14:51 -0700 Received: from robin.gentoo.org (localhost [127.0.0.1])by robin.gentoo.org (8.13.6/8.13.6) with SMTP id k4SMD7KS003610;Sun, 28 May 2006 22:13:07 GMT Received: from cicero2.cybercity.dk (cicero2.cybercity.dk [212.242.40.53])by robin.gentoo.org (8.13.6/8.13.6) with ESMTP id k4SMALei017832for gentoo-user@lists.gentoo.org; Sun, 28 May 2006 22:10:21 GMT Received: from user2.cybercity.dk (user2.cybercity.dk [212.242.41.35])by cicero2.cybercity.dk (Postfix) with ESMTP id C1DA9244F08for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST) Received: from BA.zlin.dk (port78.ds1-abs.adsl.cybercity.dk [212.242.227.17])by user2.cybercity.dk (Postfix) with ESMTP id 6BB172869D7for gentoo-user@lists.gentoo.org; Mon, 29 May 2006 00:10:20 +0200 (CEST) Sunday 28 May 2006 21:48 skrev Hemmann, Volker Armin: This change could be a bugfix. By making your own digest you don't get this bugfix... more probably - the mirror corrupted the file. Or someone replaced it with a hacked package. While that is possible I'm not really sure why you consider it more likely. At least in my case this bug showed when I upgraded from perl-cleaner-1.03 to perl-cleaner-1.03-r1. Those two ebuilds are identical and use the same tar file as source. This means that when I originally (a couple of weeks ago) installed 1.03 the digest fitted the other, smaller tar file, which means that devs has approved both versions of that tar file). It did install successfully (and seemed to work) so it couldn't be too corrupted. So while it is possible that the devs approved a file that shouldn't have been approved, I prefer to think that upstream just did something stupid by upgrading the package without a revision bump.. :) -- Bo Andresen attach3 Join the new Messenger beta now -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On 5/28/06, John Laremore [EMAIL PROTECTED] wrote: quit f John, donate your computer to charity. This whole internet thing is just not for you... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Jason Weisberger wrote: I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. Yes, very much so. See my Upgrading to gcc 4.1: emerge -e world required? thread. These packages quit on me after telling me that the reported filesize by the ebuild wasn't equal to the downloaded filesize. Were the errors correct? I mean, did the filesizes differ? I also had several packages quit on me How? If these are the type of problems we're going to see with 4.1.1, I would have to vote that it stay masked. Yep. Testing isn't even the word for this so far. I had to revert back to my 3.4.5 gcc and re-emerge system after having too many errors to warrant continuing. Hm. But there are people, who ran emerge -e world with gcc 4.1.1 and don't have problems. I suppose you'll only have problems, when you mix 3.x and 4.x. Alexander Skwar -- Fascinating, a totally parochial attitude. -- Spock, Metamorphosis, stardate 3219.8 -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Alexander Skwar [EMAIL PROTECTED] said: Jason Weisberger wrote: I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. Yes, very much so. See my Upgrading to gcc 4.1: emerge -e world required? thread. Yea, since the soname was the same, I was under the impression that mixing would be fine, and I never ran into a problem. Now that I have unmasked it and more people are testing, I see that people are actually running into issues. So, my mistake. Sorry. If you are doing any upgrade of GCC that is something like 3.3-3.4, or 3.4-4.1, recompiling everything is probably a good first step to ensuring your system will be sane. We try to cut down on work that people will have to do and see if mixed installs will work, but in this case, I was wrong that you would be able to do that. If these are the type of problems we're going to see with 4.1.1, I would have to vote that it stay masked. Yep. I've yet to see cause for saying this. Moving to a completely new version of gcc, as in 3.x - 4.x, is a huge move. I think the small amount of problems that we are seeing now is great, and if you are using ~arch, you should expect little bumps in the road. We can only do so much testing in p.mask, and all of the people using it there were telling me that it was working fine for them. Testing isn't even the word for this so far. I had to revert back to my 3.4.5 gcc and re-emerge system after having too many errors to warrant continuing. Hm. But there are people, who ran emerge -e world with gcc 4.1.1 and don't have problems. I suppose you'll only have problems, when you mix 3.x and 4.x. Just following the GCC Upgrading Guide [1], and you should be fine. There will always be a few people that run into problems, and there isn't much we can do about that. If you think you found a real bug, please report it, or we can't ever fix it. [1]: http://www.gentoo.org/doc/en/gcc-upgrading.xml -- Mark Loeser - Gentoo Developer (cpp gcc-porting qa toolchain x86) email - halcy0n AT gentoo DOT org mark AT halcy0n DOT com web - http://dev.gentoo.org/~halcy0n/ http://www.halcy0n.com pgpmcrrS3Z3f2.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
On Sat, 27 May 2006 19:40:06 +0400, Jason Weisberger [EMAIL PROTECTED] wrote: app-admin/perl-cleaner These packages quit on me after telling me that the reported filesize by the ebuild wasn't equal to the downloaded filesize. This only happened with gcc-config 6 (4.1.1). When I switched back to 3.4.5, emerge -e world was flawless. Very odd. I have just switched to gcc 4.1.1 and experienced the same. All worked out after `emerge --sync'. -- Using Opera's revolutionary e-mail client: http://www.opera.com/mail/ -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On Saturday 27 May 2006 17:40, Jason Weisberger wrote: List, I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. So far I've had just about every problem under the sun, mostly in the form of filesize errors which I wouldn't think would be related to GCC, but then again: app-admin/perl-cleaner x11-proto/xextproto x11-proto/xcmiscproto-1.1.2 These packages quit on me after telling me that the reported filesize by the ebuild wasn't equal to the downloaded filesize. This only happened with gcc-config 6 (4.1.1). When I switched back to 3.4.5, emerge -e world was flawless. Very odd. so run ebuild blabla.ebuild digest wow, that is hard... if you are trying software from the ~ tree, you are expected to deal with some hiccups. btw, I did the gcc 3.4.x--4.1 step some weeks ago. And just to be safe, I did an -e system followed by an -e world. Was a good decision - I did not run in any major problems. -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On 5/27/06, Jason Weisberger [EMAIL PROTECTED] wrote: List, I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. So far I've had just about every problem under the sun, mostly in the form of filesize errors which I wouldn't think would be related to GCC, but then again: app-admin/perl-cleaner I think this has nothing to do with the gcc upgrade. More likely it is simply because you were doing an emerge -e world. I see the same thing on my system: checking perl-cleaner-1.03.tar.gz !!! Digest verification failed: !!! /usr/portage/packages/sources/perl-cleaner-1.03.tar.gz !!! Reason: Filesize does not match recorded size !!! Got: 4954 !!! Expected: 4611 ~ grep perl-cleaner-1.03.tar.gz /usr/portage/app-admin/perl-cleaner/Manifest DIST perl-cleaner-1.03.tar.gz 4611 RMD160 2008ea90c056c4db5f1e897dcf9b4fc56c4bc2ea SHA1 22b83c8266518ee0e42a5648ac3715bdfb7f8a68 SHA256 fe41245499829c473dc27afe76c328341ffa04933873a905d29b5d48e56218b3 ~ ls -l /usr/portage/distfiles/perl-cleaner-1.03.tar.gz -rw-rw-r-- 1 root portage 4954 Feb 20 07:02 /usr/portage/distfiles/perl-cleaner-1.03.tar.gz So the Manifest really does list 4611 bytes as the expected size, but my distfile is 4954 bytes. Most likely the Manifest was updated (via an emerge --sync) after I merged 1.03. But there was no bump in the ebuild version, so I never saw this on any of my normal upgrades...not until I tried to merge it again. These packages quit on me after telling me that the reported filesize by the ebuild wasn't equal to the downloaded filesize. This only happened with gcc-config 6 (4.1.1). When I switched back to 3.4.5, emerge -e world was flawless. Very odd. Can you elaborate on this? I cannot duplicate it: carcharias ~ # gcc-config 1 * Switching native-compiler to i686-pc-linux-gnu-3.4.6 ... Regenerating /etc/ld.so.cache... [ ok ] * If you intend to use the gcc from the new profile in an already * running shell, please remember to do: * # source /etc/profile carcharias ~ # source /etc/profile carcharias ~ # emerge --oneshot perl-cleaner Calculating dependencies... done! Emerging (1 of 1) app-admin/perl-cleaner-1.03 to / checking ebuild checksums ;-) checking auxfile checksums ;-) checking miscfile checksums ;-) checking perl-cleaner-1.03.tar.gz !!! Digest verification failed: !!! /usr/portage/packages/sources/perl-cleaner-1.03.tar.gz !!! Reason: Filesize does not match recorded size !!! Got: 4954 !!! Expected: 4611 In any case this should be solved by deleting the offending distfiles and letting them be downloaded again. I also had several packages quit on me related to gnome and GTK. Complaints were usually related to GTK being compiled and installed, however would not run. Without more data (the specific error messages), it is hard to say whether this is related to the 4.1.1 upgrade or not. -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On 5/27/06, Hemmann, Volker Armin [EMAIL PROTECTED] wrote: so run ebuild blabla.ebuild digest wow, that is hard... Probably better to just delete the distfiles and let them be downloaded again though... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
List, I suppose that I just found it odd that it popped up after I switched to GCC 4.1.1. Maybe coincidence. I'll delete all my digest files and let them download again, because this is popping up on quite a few packages. Maybe a bad mirror. I will be going on vacation for about a week, and when I get back I'll try to do all this again, hell, maybe even from a fresh install. I hear the benefits are worth it. I've read a few things about 4.1.1 not playing well with GTK packages on the forums, however, and that still appears to be the case. I'll get exact error messages when I return and bring this thread up again. Thanks to everyone who responded! -- Jason Weisberger [EMAIL PROTECTED] -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
On 5/27/06, Jason Weisberger [EMAIL PROTECTED] wrote: I've read a few things about 4.1.1 not playing well with GTK packages on the forums, however, and that still appears to be the case. I'll get exact error messages when I return and bring this thread up again. Cool. Hopefully any problems will have ready-made solutions by then. Have a nice vacation... -Richard -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] GCC 4.1.1 Problems
Saturday 27 May 2006 23:22 skrev Jason Weisberger: I will be going on vacation for about a week, and when I get back I'll try to do all this again, hell, maybe even from a fresh install. I hear the benefits are worth it. What benefits? -- Bo Andresen pgpt3NNfGxdh5.pgp Description: PGP signature
Re: [gentoo-user] GCC 4.1.1 Problems
Jason Weisberger wrote: List, I figure upgrading to GCC 4.1.1 from 3.4.5 wouldn't be such a pain, right? WRONG. So far I've had just about every problem under the sun, mostly in the form of filesize errors which I wouldn't think would be related to GCC, but then again: app-admin/perl-cleaner x11-proto/xextproto x11-proto/xcmiscproto-1.1.2 I had this same issue with app-admin/perl-cleaner. I think there is a bad tarball on some of the mirrors. I grabbed this one: http://www.gtlib.gatech.edu/pub/gentoo/distfiles/perl-cleaner-1.03.tar.gz and saved it to /usr/portage/distfiles and then ran this (one line): ebuild /usr/portage/app-admin/perl-cleaner/perl-cleaner-1.03.ebuild digest Now it merged in fine. Jim -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= There's no place like 127.0.0.1 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= JimD Central FL, USA, Earth, Sol -- gentoo-user@gentoo.org mailing list
