Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Installing Gentoo 2004.3: Stage 1 NPTL on a Stage 3 Tarball
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 16, 17, 18  Next  
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks
View previous topic :: View next topic  
Author Message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Feb 13, 2005 9:42 pm    Post subject: Reply with quote

SaFrOuT wrote:
as mentioned before this guide is really 100% AMAZING
...
again and again and again THANKS a lot Bob P for this wonderful and clean guide and please keep it up2date for every new gentoo user or re-installer to be able to use it :) (emphasis added)

i'm very glad to hear that everyone has enjoyed this installation method so much. :cool:

regarding me keeping the guide up to date for the benefit of new gentoo users: No -- Its not going to happen. :cry:

this Guide is not a step by step installation handbook for new users. it has never been intended to be that, and it will never be intended to be that -- even though some people are looking at it that way now.

this Guide comprises a conceptual basis for how to build a clean, fast, and robust Gentoo installation, including detailed instructions on how to properly build a system toolkit using a specific set of packages. no support is provided beyond what has been written into the guide. its a fact of life that gentoo is going to change. anyone who reads this guide and understands the underlying concepts shouldn't have any problem adapting it to Gentoo as packages are updated. :idea: those who read this guide and don't understand the underlying concepts well enough to apply them should probably use one of the traditional installation methods.

if you're one of the people who understand the guide and you think that package masking is necessary, then its something that you should try. if you find an updated package that is newer than the ones used in this tutorial, try it. if it works, then report back to us. if it fails, then try another approach. ultimately, the end user who uses this installation method is responsible for his own system, regardless of whether he decides to use the stable branch or the testing branch, or whether he decides to use the actual packages that i used when i wrote the Guide, or newer packages that have since replaced them.

i think that some of you guys are seriously mis-guided when you expect that anyone has the resources to undertake some kind of everlasting commitment to keep this guide as current as the portage tree. from a practical standpoint, what you ask is not humanly possible. to keep the guide continually up to date, somebody would have to be performing test installations on multiple PCs every time that the portage tree is updated. the impossible nature of that task should not be lost on anyone.

instead of expecting to be spoonfed as every package is updated, my recommendation to the user would be to read the guide, assimilate its underlying concepts, and apply them to your situation. its not my job to continuously update this document -- rather, it is your job to learn the lesson that i am teaching, to climb to an admittely low plane of enlightenment, and to apply what you have learned. :wink:

with that in mind, YES, i will occasionally update this guide, but because i have other commitments, i won't be updating it often enough to keep everyone happy. :?


PS - those of you interested in GCC 3.4.3.2005<whatever> should check out this thread:
https://forums.gentoo.org/viewtopic-t-283801.html

Edit: typos
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks


Last edited by Bob P on Mon Feb 14, 2005 8:51 pm; edited 1 time in total
Back to top
View user's profile Send private message
Arainach
l33t
l33t


Joined: 08 Jul 2004
Posts: 609

PostPosted: Sun Feb 13, 2005 10:00 pm    Post subject: Reply with quote

That would certainly work, but to get the full benefit, you'd have to re-emerge gcc-3.4.3-r1 with gcc-3.3.4 (or 3.4.3.20050110 if it can build it, but I don't think that it can) and then rebuild your entire toolkit with gcc-3.4.3-r1 before doing the emerge -e system. Yes, it's long. But I can now safely say that it's definatley worth it.
_________________
Gentoo: Stage3 w/ NPTL & udev, gcc 3.4.4 full rebuild
Kernel: 2.6.15-gentoo-r1 w/ 1G-Lowmem Patch
System: Athlon XP 2.2Ghz/1GB Corsair Value/160GB, 250GB WD IDE/128MB GeForce 6800/Sony 17" Trinitron G200 @ 1280x1024x75Hz
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Sun Feb 13, 2005 11:24 pm    Post subject: Reply with quote

thebigslide wrote:
Bob, would it make sense to add a line:
Code:
echo '>sys-devel/gcc-3.4.3-r1' >> /etc/portage/package.mask'
to the howto? It implies the answer to the above question. Just a thought.

it depends what you're trying to accomplish. adding 3.4.3-r1 to package.mask is going to prevent you from using that package. adding 3.4.3.20050110 to the package mask might get you closer if your objective is to use 3.4.3-r1 and not use 20050110. the problem with package masking approaches like this is that they become a real PITA.

i'm just wondering -- in your example, were you trying to facilitate the use of 3.4.3-r1 and avoid the use of 20050110? if you're trying to do that, a better method would be to provide the desired version in the package.keywords file. consider this example from the GIH -- i feel kind of silly posting this, as i'm sure that everyone has already RTFM and should already be familiar with it: :wink:


Gentoo Installation Handbook wrote:
Test Particular Versions

If you want to use a specific software version from the testing branch but you don't want Portage to use the testing branch for subsequent versions, you can add in the version in the package.keywords file. In this case you must use the = operator. You can also enter a version range using the <=, <, > or >= operators.

In any case, if you add version information, you must use an operator. If you leave out version information, you cannot use an operator.

In the following example we ask Portage to accept gnumeric-1.2.13:

Code Listing 4: Using a particular gnumeric version

Code:
=app-office/gnumeric-1.2.13


ultimately, the decision of whether or not to use a particular verison of GCC from the testing branch or the latest version of GCC in the testing branch is a decision that the individual user has to make, based upon their review of the current GCC-related threads in the forum. this isn't a decision that the guide is going to make on your behalf. if you're comfortable using the most current version of GCC provided in the testing branch, then use the guide as it is written. if you're not comfortable using the most current version of GCC provided in the testing branch, then it should be clear how to configure portage to use a particular version that you want to use.

just for reference: my stable branch systems are using GCC 3.4.3-r1, while my testing branch systems are using GCC 3.4.3.20050110. none of them have had any problems with any of the software i've installed on them. YMMV.

somebody sent me a PM asking where my "packages.provided" file was in the guide. :wink: would anyone care to answer that one for the class? :idea:

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Sun Feb 13, 2005 11:38 pm    Post subject: Reply with quote

Bob P wrote:
somebody sent me a PM asking where my "packages.provided" file was in the guide. :wink: would anyone care to answer that one for the class? :idea:

packages.provided? What is that for? :-P

It's not listed as one of the user-configurable files under /etc/portage in the Portage docs.

P.S. And this happens to be my first post in this topic as veteran. :-D
_________________
Murphy's Law of Gentoo installation: If a compile can fail, it will.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
DrWoland
l33t
l33t


Joined: 13 Nov 2004
Posts: 603

PostPosted: Mon Feb 14, 2005 12:33 am    Post subject: Reply with quote

kimchi_sg wrote:
Bob P wrote:
somebody sent me a PM asking where my "packages.provided" file was in the guide. :wink: would anyone care to answer that one for the class? :idea:

packages.provided? What is that for? :-P

It's not listed as one of the user-configurable files under /etc/portage in the Portage docs.

P.S. And this happens to be my first post in this topic as veteran. :-D

Congrats, kimchi 8)
_________________
I'm not a Guru, I just ask a lot of questions.
Back to top
View user's profile Send private message
thebigslide
l33t
l33t


Joined: 23 Dec 2004
Posts: 790
Location: under a car or on top of a keyboard

PostPosted: Mon Feb 14, 2005 12:45 am    Post subject: Reply with quote

Bob P wrote:
thebigslide wrote:
Bob, would it make sense to add a line:
Code:
echo '>sys-devel/gcc-3.4.3-r1' >> /etc/portage/package.mask'
to the howto? It implies the answer to the above question. Just a thought.

i'm just wondering -- in your example, were you trying to facilitate the use of 3.4.3-r1 and avoid the use of 20050110?


Yes. There is no =.
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 6:06 am    Post subject: Reply with quote

Quote:
yes. there is no =.


D'Oh! :oops: i should have read that ">" more closely.

as your post and the "packages.provided" question shows us, there are more ways than one to skin a cat. :twisted:

you can use the masking method that you've mentioned, but it involves editing two different portage files to enable a single version of GCC; you have to edit package keywords to enable gcc in the testing branch, and then you have to edit package.mask to mask subsequent versions. IMHO, this amounts to doing things the hard way. when i do this sort of thing, i try to modify the smallest number of config files, because -- my memory being what it is -- when its time to undo something, i won't remember to modify one of the files and something will get buggered-up. :oops:

in contrast, if you stick with the package.keywords approach, you only have to modify a single file. :wink:

feel free to do it whichever way you like -- either method should work fine. 8)

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Zuti
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jul 2003
Posts: 123
Location: The Netherlands

PostPosted: Mon Feb 14, 2005 7:19 am    Post subject: Reply with quote

A brief summary:
I have an AMD 2400+ XP. Gentoo I use was installed almost year ago (I think it was 2004.0, not sure).
Every now and then when i wanted to upgrade glibc/gcc I used the method of emerging system twice and then emerge -e world.
I always used CFLAGS="-O3 -march=athlon-xp -fomit-frame-pointer -pipe" .

Well, after reading Bobs guideline I couldn't resist so I upgraded to 3.4.3 and changed my CFLAGS to those Bob recommended (I changed pentium for athlon).
I dont use ~x86 for my packages (only for toolchain related things in package.keywords, described in Bobs manual).

Now I read gcc-3.4.3.20050110 has some issues and that gcc-3.4.3-r1 should work better (faster?). I dont have any prob's and everything works great.
My questions are:
- what are the specific probs you have with gcc-3.4.3.20050110?
- im also interested in CFLAGS kimchi_sg posted for athlon xp, so my question to him is how stable/faster are they, and if it's worth changing (and I'm not planning on putting my system on the edge with ~x86 for packages)?
My system is stable and fast and I would like to keep it that way (this is the only OS i have at home, although I emulate windows with vmware).

thanks.
Back to top
View user's profile Send private message
kimchi_sg
Advocate
Advocate


Joined: 26 Nov 2004
Posts: 2915
Location: Singapore

PostPosted: Mon Feb 14, 2005 7:52 am    Post subject: Reply with quote

Zuti wrote:
Now I read gcc-3.4.3.20050110 has some issues and that gcc-3.4.3-r1 should work better (faster?). I dont have any prob's and everything works great.
My questions are:
- what are the specific probs you have with gcc-3.4.3.20050110?

For the reasons why gcc-3.4.3-20050111 was and still is masked, check out the Changelog in your /usr/portage/sys-devel/gcc/ directory. Notably, it b0rks on -fstack-protector, iirc.
Zuti wrote:
- im also interested in CFLAGS kimchi_sg posted for athlon xp, so my question to him is how stable/faster are they, and if it's worth changing (and I'm not planning on putting my system on the edge with ~x86 for packages)?
My system is stable and fast and I would like to keep it that way (this is the only OS i have at home, although I emulate windows with vmware).

thanks.

To keep things stable for as long as possible, i would advise you not to try my CFLAGS. And especially resist the temptation to re-install according to this tutorial.

All i can say about my CFLAGS is that they have not been the specific cause behind any of my emerge failures so far.

If your system is stable and zippy as it is now, great! No need to tweak anything if it is already in good working condition. :-D

You may even unmerge gcc-3.4.3 if you feel guilty about having tried anything ~x86.
_________________
Murphy's Law of Gentoo installation: If a compile can fail, it will.

MacGillicuddy's Corollary: At the most inopportune time.

Please search and read the FAQs before posting.
Back to top
View user's profile Send private message
Zuti
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jul 2003
Posts: 123
Location: The Netherlands

PostPosted: Mon Feb 14, 2005 8:28 am    Post subject: Reply with quote

Thank you for the fast reply, i thought it wouldnt be a good idea(tm).
these are my flags now
Code:
CHOST="i686-pc-linux-gnu"
CFLAGS="-O3 -march=athlon-xp -mtune=athlon-xp -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"

Dunno, maybe I'm lucky or something, but i dont have any probs with gcc-3.4.3.20050110.
Im not planning on going back to 3.3.5. Everything is stable and Im very much happy with it, only thing is: I didnt feel the speed improvment as much as I was hoping I would.
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 8:45 am    Post subject: Reply with quote

Hmm seams that "emerge -e system" stopped during the night while compiling libstdc++ with gcc-3.4.3-rc1 also
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Mon Feb 14, 2005 12:10 pm    Post subject: Reply with quote

--

Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 2 times in total
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 7:34 pm    Post subject: Reply with quote

nightmorph wrote:
Bob P wrote:
mtamizi wrote:
Bob P: Thanks for this tutorial. It was very useful.

About the CFLAGS. Most people are using those extra flags without realizing it, ie, some of the flags you listed are redundent. According to GCC optimization website, -O3 already includes a lot of those options -- like -fomit-frame-pointer.

indeed, you are right. whenever you turn on any level of optimization using -Ox, -fomit-frame-pointer is enabled. you will get -fomit-frame-pointer at -O1, for example.

similarly, when you turn on level -O3, -frename-registers and -fweb are enabled. i'll fix that. thanks.


First, according to the GNU gcc website, -fomit-frame-pointer is only enabled for machines that do not debug; x86 and x86-84 should still specify this. Also, it's not a bad idea to explicitly declare the optimizations implied by -O3 as many ebuilds disable -O3 optimizations, switching to -O2 instead. This way certain functions (like -fweb and -frename-registers) are preserved even if some other processor-specific functions are removed. This should keep my Pentium III noticeably faster, instead of losing some key optimizations.

Thanks for your feedback on the CFLAGS. I seem to remember this conversation popping up already, but I don't remember if it came along in this thread (maybe it was Hobbitt?) or if it came up in one of the other threads. You're definitely right, -fomit-frame-pointer doesn't come along automatically when optimizing on x86 as it does on other hardware. In some respects, I think that this is moot, though, as the guide specifically mentions turning-on "-fomit-frame-pointer" when the "-O3" optimization level is used:

Stage 1/3 Guide wrote:

7.2.1 Updating make.conf

Here are some settings for /etc/make.conf that may be worth considering. They are the actual CFLAGS that I used to build my systems and have proven reliable on multiple installations. They include extreme levels of code optimization (notice the -O3 flag), and some very safe and stable performance-enhancing CFLAGS. Depending upon your individual hardware, you may have to simplify some of the CFLAGS settings. Note that the referenced architecture in this example is Intel Pentium.

Code:
CFLAGS="-O3 -march=pentium -mtune=pentium -fforce-addr -momit-leaf-frame-pointer -fomit-frame-pointer -ftracer -pipe"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"



The need to set "-fomit-frame-pointer" independently of "-O3" on x86 platforms is displayed again in an example on this post on page 7 of the thread. Maybe I didn't make these points clear enough, so thanks for pointing out the architecture-specific idiosyncrasy for x86 and bringing up the fact that this may not be clear in the guide. I'll put that on my list of things to update. :wink:

nightmorph wrote:
...
Also, it's not a bad idea to explicitly declare the optimizations implied by -O3 as many ebuilds disable -O3 optimizations, switching to -O2 instead. This way certain functions (like -fweb and -frename-registers) are preserved even if some other processor-specific functions are removed.

I've got a question for you about this -- if an e-build contains instructions to specifically disable -O3 optimizations, how effective will it be to manually/redundantly specify the CFLAGS that are contained in -O3? For the approach of redundantly listing CFLAGS to be at all successful, it would seem that the ebuild's CFLAG-disabling method would have to be defective -- ie: it would have to be ignorant of what CFLAGS are turned-on automatically with the -O3 level of optimization. It would surprise me very much if every ebuild developer were careful enough to filter -O3, yet careless enough not to filter the actual flags specified by -O3. Maybe I'm wrong and I'm just giving developers too much credit -- for being able to actually accomplish their programming goals. :?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 8:13 pm    Post subject: Reply with quote

Lucifeer wrote:
the only problem I had was when re-emerging libdc++ during the "emerge -e system"-step, for some reason it refused to be compiled and gave me an error. Switching to gcc-3.3.4 for this package and abusing emerge --resume to switch to gcc-3.3.4 with gcc-config for this package was the workaround for me...

Wonder if that package will create future problems now =/ Oh well all I can do is wait

Lucifeer wrote:
Hmm seams that "emerge -e system" stopped during the night while compiling libstdc++ with gcc-3.4.3-rc1 also

it appears evident that you've deviated from the guide by using toolkit packages older than those specified. you've also compiled tooklit components with two different compilers :!:

you should reconsider this approach and pursue your support request in one of the support forums.

_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks


Last edited by Bob P on Mon Feb 14, 2005 8:17 pm; edited 1 time in total
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 8:16 pm    Post subject: Reply with quote

older then those specified? Care to explain that abit more?

I followed the guide almost exactly, how can they be older then?
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 8:24 pm    Post subject: Reply with quote

Lucifeer wrote:
older then those specified? Care to explain that abit more?

NO. THIS IS NOT A SUPPORT FORUM.

Lucifeer wrote:
I followed the guide almost exactly, how can they be older then?

unfortunately, "almost exactly" doesn't cut it.

it is beyond the scope of this guide to discuss the problems that you encounter when deviating from it. if you have followed the Guide and you need support, you should post in the support forums, not here. if you've encountered a problem with the Guide by deviating from it, you should post in the support forums, not here.

PS - removing any non-relevant material from the thread will help to keep it readable for people who are trying to follow the guide.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 8:27 pm    Post subject: Reply with quote

You should stop with that attitude.
I never did ask for help, I just noted something that happened while following the guide.

And I doubt you know what I meant with "almost exactly" anyways, I followed the guide _except_ for your machine's hardware. AND later on tried to solve something else by changing compiler-version.

And I did ask you to simplify what you said as I didn't understand it, sorry for not being an american then
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Mon Feb 14, 2005 8:53 pm    Post subject: Reply with quote

--

Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 5 times in total
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 9:09 pm    Post subject: Reply with quote

Lucifeer wrote:
You should stop with that attitude.
I never did ask for help, I just noted something that happened while following the guide.

And I doubt you know what I meant with "almost exactly" anyways, I followed the guide _except_ for your machine's hardware. AND later on tried to solve something else by changing compiler-version.

And I did ask you to simplify what you said as I didn't understand it, sorry for not being an american then

American? what does anyone's nationality have to do with anything?

"older than those specified." how much clearer could this possibly be?

Its evident that you did not follow the Guide -- you compiled toolkit components with a mixture of GCC 3.4.3 and GCC 3.3.4, even though the guide specifically requires that you compile your toolkit redundantly with GCC 3.4.3. It should come as no surprise to anyone that problems would ensue when following such a deviant course. When you don't follow the guide, I don't want to hear about your problems.

In regard to my attitude -- in order to be consistent and fair to everyone else who's been stomped-on for posting support requests in this thread, it is my duty to politely ask people who stray from the guide to take their support requests elsewhere. When people refuse to pay attention to boldfaced red requests and persist under the assumption that the rules do not apply to them, the time for politeness has passed. It was unfortunate that you choose to ignore the hints that had been provided for you.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 9:32 pm    Post subject: Reply with quote

Bob P wrote:
American? what does anyone's nationality have to do with anything?

"older than those specified." how much clearer could this possibly be?
Spoken and written language thats what, Im from none of the english-speaking contries. Your message made no sense so it might have been my lack of english knowledge that caused me to not understand it I thought.

Bob P wrote:
Its evident that you did not follow the Guide -- you compiled toolkit components with a mixture of GCC 3.4.3 and GCC 3.3.4, even though the guide specifically requires that you compile your toolkit redundantly with GCC 3.4.3. It should come as no surprise to anyone that problems would ensue when following such a deviant course. When you don't follow the guide, I don't want to hear about your problems.
Wtf? Quote from your guide:
Quote:
Before we do this we need to examine /etc/make.conf and make changes to the CFLAGS statements in order to take advantage of the new performance-enhancing features of GCC 3.4.3. After making necessary updates to /etc/make.conf we need to rebuild the toolkit using the new GCC 3.4.3 compiler. The result will be a 3.4.3 tooklit, compiled by a 3.4.3 toolkit that was built with a 3.3.4 toolkit. Clear as mud? Rolling Eyes
YOUR _supposed_ to mix 3.3.4 and 3.4.3 acording to you how did I not follow the guide?

And second time I did follow your guide, but I began anew from scratch but using gcc-3.4.3-rc1 instead of the other unstable gcc-3.4.3
Back to top
View user's profile Send private message
96140
Retired Dev
Retired Dev


Joined: 23 Jan 2005
Posts: 1324

PostPosted: Mon Feb 14, 2005 9:43 pm    Post subject: Reply with quote

--

Last edited by 96140 on Fri Sep 13, 2013 9:39 am; edited 1 time in total
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 9:46 pm    Post subject: Reply with quote

well thats what I did, except I had to switch to 3.3.4 for one package wich refused to compile with 3.4.3 for some reason
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 9:56 pm    Post subject: Reply with quote

nightmorph wrote:
Here's the relevant information I learned from a very helpful software developer:

moocha wrote:
-fweb -frename-registers are theoretically redundant (they're included in -O3) but the vast majority of ebuilds strip out -O3 replacing it with -O2, and this way the corresponding optimizations get kept. On a P3 arch they're perfectly safe, and are quite noticeable.


It would indeed seem that many developers just strip out the -O3 optimization, but it is still possible to add in some of the theoretically "less stable" (though they really are perfectly safe) optimizations encountered at the -O3 level. Another idea is that when moving from -O2 to -O3, the packages built will definitely start to increase in size somewhat, and stripping out -O3 may be a somewhat misguided attempt to help keep down file sizes.

i'm still not sure that i understand what the ebuild developers are doing when the strip out the -O3 optimization. are they just searching for the text "-O3" and replacing it with "-O2", or are they specifically looking for the individual flags that are implied in "-O3" and removing them as well? as you can see, these two approaches will provide significantly different results at compile time if one specifies both "-O3" and the flags that are implied in "-O3". in the first scenario, where the ebuild changes "-O3" to "-O2", you can bypass the stripping process by specifying the implied cflags. in the second scenario, redundant specification of individual flags won't help. whether or not our efforts to manually specifiy implied flags are successful depends entirely upon the individual ebuild's flag filtering algorithm. personally, i find it beyond the scope of my willingness to inspect all of the individual ebuilds. :?
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Bob P
Advocate
Advocate


Joined: 20 Oct 2004
Posts: 3355
Location: Jackass! Development Labs

PostPosted: Mon Feb 14, 2005 9:56 pm    Post subject: Reply with quote

nightmorph wrote:
Mmm, I meant to ask you--were it not for the fact that many users have had trouble with versions of gcc beyond 3.4.3-r1, would you otherwise wholeheartedly recommend it? I remember reading earlier in this thread about your experience with gcc 3.4.3.20050110, and it sounds like the dream compiler for this install method. Is the speed boost so noticeable even over more "stable" versions of gcc 3.4.x?

i have experienced none of the problems that have been reported with any of the releases of gcc 3.4.3. i have both gcc 3.4.3-r1 and 20050110 installed on my systems and i have never had problems with either one of them. actually, i have never heard of an instance where a knowledgeable user has had problems with any of the gcc 3.4.3 ebuilds when following this guide. so i am at a loss to explain why people are having problems with any of the 3.4.3 ebuilds.

building the toolkit the way that i do, i have never encountered the problem. in reading many of the threads that have discussed "issues" with gcc 3.4.3, i got the impression that the common denominator among people having problems was attributable to using update methods like "emerge -uD world" and not following the robmoss method of redundantly rebuilding the toolkit after a compiler upgrade. (i could be wrong on that). insofar as i have never observed these problems, i am of the impression that gcc 3.4.3 has been given a bad rap by users who have botched the upgrade and didnt' realize what they're doing wrong . to discuss this, we should really be moving over to the GCC 3.4.3 threads. my opinion is that it is safe to use gcc in the testing branch.
_________________
.
Stage 1/3 | Jackass! | Rockhopper! | Thanks | Google Sucks
Back to top
View user's profile Send private message
Lucifeer
Tux's lil' helper
Tux's lil' helper


Joined: 09 Jun 2004
Posts: 110
Location: Sweden

PostPosted: Mon Feb 14, 2005 9:58 pm    Post subject: Reply with quote

nightmorph wrote:
Lucifeer wrote:
well thats what I did, except I had to switch to 3.3.4 for one package wich refused to compile with 3.4.3 for some reason

That's a significant deviation from the published guide. Now that you know (for sure) that not once that Bob P required you to mix compilers, you've no excuse if something breaks. For that matter, this method is not guaranteed to work. In your case, you've proved that it doesn't work for you, or at least not with gcc 3.4.3. If you're still interested in it, try out one of the other gcc versions. Post about your experiences. But it's unreasonable to expect much help if you deviate from the guide in this way. If the issue was purely a gcc 3.4.3 problem, that might be relevant, in which case you might post a thread or bug report elsewhere.

And if your package still won't compile, look into a different version that does the same thing. Or examine your make.conf and post a support request on a different forum. Sorry, but if this method requires you to use an older gcc every time to make your system work, than this method isn't for you.

Your mileage may vary.
Thats a better explanation. I just didn't understand it the way he put it wich is why I had to ask what he meant, instead of him getting angry for no reason at all.

So thank you
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Documentation, Tips & Tricks All times are GMT
Goto page Previous  1, 2, 3 ... 9, 10, 11 ... 16, 17, 18  Next
Page 10 of 18

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