On Friday 19 January 2007 00:24, b.n. wrote: > Hi, > > Quite late :), I'm going to do my homework, that is the loooong > upgrade to gcc 3.4.x --> 4.1.x > > The subject has been widely discussed, so I've just a couple of > questions to be super-safe: > > - I'm going to follow [1] (of course) and [2] (looks nice). Other > useful guides?
Those two cover everything you will need to know in just about all cases > - Is there a new incompatible GCC upgrade going to be unmasked? I see > 4.2 and 4.3 are hard masked, but if there is the suspicion they're > going to be used relatively soon AND they are not binary compatible > with 4.1, I may wait for those. When I did 3.3-->3.4, I waited long, > and 4.1 became stable after a week... :/ Dunno about gcc-4.2, you'll have to look at the gnu roadmap to get a hint of when they think it'll move closer to a release > - Is it mandatory/highly advisable to recompile also the kernel, or > can I postpone? In the first case, when it's better to recompile it > (before all/after all)? Not at all necessary. The kernel is a free standing block of C code and depends only on itself, so ABI issues with other apps simply don;t happen. As long as the kernel and all it's modules were compiled with the same compiler you will always be fine. (There are exceptions of course but with that rule of thumb you can't go wrong) > - Do I have to emerge glibc 2.4 first and gcc later, or I can have > glibc emerged in the emerge -e system? No, just let glibc get recompile along with everything else in emerge -e system. Even if there are some oddities of things still linked against older versions after that step, the following emerge -e world fixes all that > - Any other glitch/tarpit I must be aware of? Make sure any kernel modules you may have that are not in portage also get recompiled. If you have something like this you already know all about it, so I don;t need to give examples. alan -- [email protected] mailing list
