GCC 4.1.1 and glibc 2.4 going stable!

Message

dleverton · Post by **dleverton** » Mon Aug 28, 2006 6:02 pm

Carlo wrote:Bugs like [bug]64615[/bug] and [bug]123065[/bug] should be enough as evidence (for the C++ ABI at least).

Yeah, I'm not surprised about the C++ stuff. I wouldn't have thought there'd be incompatible changes for C, but that's what the current advice seems to suggest.

Carlo wrote:
dleverton wrote: What happens to binary-only packages, for example? Do they just stop working until upstream releases a new version?
Depends what you mean. You can install multiple libraries providing different ABI's, so commercial applications don't stop working, but if you link dynamical to other libraries, they need to have the same ABI and it doesn't matter, if you actually try to compile against an incompatible one or if you install a binary package and the installed application is not compatible.

I mean, as I understand the upgrading instructions, applications built with GCC 3.4 need to use libraries built with GCC 3.4, and similarly for 4.1. Presumably that includes things like glibc, Xlib and such, so as soon as you rebuild the system with GCC 4.1 all the old binary apps will stop working (none of the binary apps on my machine have their own copy of either of the mentioned libraries, AFAICT). Or am I getting the wrong end of the stick?

Carlo · Post by **Carlo** » Mon Aug 28, 2006 6:45 pm

dleverton wrote:I wouldn't have thought there'd be incompatible changes for C, but that's what the current advice seems to suggest.

As I said, ask our toolchain guys. I've no interest to dig deeper and trust them.

dleverton wrote:I mean, as I understand the upgrading instructions, applications built with GCC 3.4 need to use libraries built with GCC 3.4, and similarly for 4.1. Presumably that includes things like glibc, Xlib and such, so as soon as you rebuild the system with GCC 4.1 all the old binary apps will stop working (none of the binary apps on my machine have their own copy of either of the mentioned libraries, AFAICT). Or am I getting the wrong end of the stick?

If you have two not overlapping dependency trees A and B, you can built A with another compiler (ABI) than B. As soon as you want to rebuild one library or application of A with the compiler version you used for B, all of A has to be built with this compiler version (or one which is ABI compatible to it).

Gooserider · Post by **Gooserider** » Tue Aug 29, 2006 1:04 am

<3
When you unmask glibc 2.4.x you should do a emerge -e system && emerge -e world. But since you are already doing that with the gcc upgrade its a good idea to unmask glibc at the same time.

Thanks for the info, I will do that now, hope it doesn't cause to much of a problem to do it in the middle of the upgrade. I've done the "emerge -e system" but I haven't done the world yet.

Not your fault, but it really annoys me that there was NOTHING about how to upgrade the library in either the newsletter OR the GCC Upgrade instructions. The newsletter pointed us at the GCC Upgrade manual, but had NO pointers to any sort of library instructions.

On a dino box like this it takes DAYS to do emerge -e system, and I hate to think about how long world will take. While the recompile is happening, the system is sort of usable, but gets REALLY slow (as if it wasn't already!) I don't like a doc failure that makes you have to do the recompile twice!

I will be filing a bug on this for sure!

Dralnu · Post by **Dralnu** » Tue Aug 29, 2006 1:47 am

Gooserider:

Try the nice setting in make.conf. That may help with usability durning emere, although it will prolong the agony.

Gooserider · Post by **Gooserider** » Tue Aug 29, 2006 3:02 am

Hmmm... I posted on this a couple minutes ago, but my post seems to have gotten munched somewhere...

I did post the bug that I promised a couple of posts back for all the good it did

(Bug # 145430) I just got it back with a "Resolved Invalid" stamp on it. I got this reply from the Dev, who seems to think it isn't necessary to recompile the system, though he didn't explain his reasoning or exactly what he thought SHOULD be done...

------- Comment #1 From SpanKY 2006-08-28 18:40 PST [reply] -------
incorrect

glibc-2.4 will be going stable when gcc-4.1.1 goes stable; since gcc-4.1.1 is
not stable yet then neither is glibc-2.4

as for having to recompile world, that's complete garbage

I can't complain about slow service on this one, but I'm not sure the problem was really addressed. Do they have new docs that are waiting to be released when gcc / glibc go stable? If so, how does one get access to DOCS in 'testing'???

Gooserider

Gooserider · Post by **Gooserider** » Tue Aug 29, 2006 3:25 am

Dralnu
Try the nice setting in make.conf. That may help with usability durning emere, although it will prolong the agony.

I might try that Dralnu, but I'm not sure how much good it will do. As I understand it, "nice" mostly works on the processor part of things. However it looks like what really slams my box is the hard drive, or at least there appears to be a direct correlation between how slow things get and the intensity of the drive LED. When the box gets to doing heavy disk I/O everything else slows to a total crawl. When it isn't flogging the disk, the speed is tolerable.

I suspect part of the issue is that the box used to "only" have 128Mb of RAM (Which cracks me up a bit since I remember when you were doing well to have 640Kb

) I think this led to me spending alot of time swapping to disk, which will certainly slow things down. After my emerge system finished this morning, I took the box down for some parts shuffling, and was able to bump the RAM up to 320Mb

Hopefully this will speed things up by letting me spend less time swapping.

Also I've finally made the time to get another box built up that is slightly less antiquated

. It has a Gigabyte K7 Triton mobo w/ an Athlon XP 2500, 512 MB of RAM and a GeForce video card. I hope all the Nvideous chips won't force me into proprietary modules, but... The box is MUCH faster - This Celeron box took about 1 hour / pass w/ memtest 86 on 320Mb. The new box is taking about 20 minutes / pass on 512 Mb.

Also to test the floppy and hard drives, I installed MS-Doze on the HD. From the time the hard drive started to boot to a DOS prompt was just a couple of seconds. Once I get Gentoo installed, and everything moved over, one of these boxes will probably turn into a Linux from Scratch box just for the learning experience.

Gooserider

Gooserider

loki99 · Post by **loki99** » Tue Aug 29, 2006 9:49 am

Gooserider wrote:
------- Comment #1 From SpanKY 2006-08-28 18:40 PST [reply] -------
incorrect

glibc-2.4 will be going stable when gcc-4.1.1 goes stable; since gcc-4.1.1 is
not stable yet then neither is glibc-2.4

as for having to recompile world, that's complete garbage
I can't complain about slow service on this one, but I'm not sure the problem was really addressed. Do they have new docs that are waiting to be released when gcc / glibc go stable? If so, how does one get access to DOCS in 'testing'???

You seem to missunderstand. There will be no need to mention it explicitly, since glibc automatically gets updated when you follow the instructions from the GCC update guide. The appropriate glibc will be made stable when gcc-4.1.1 becomes stable so there will be no need to unmask it.

And if you are running testing, you are expected to know what you are doing.

loki99 · Post by **loki99** » Tue Aug 29, 2006 10:26 am

Gooserider wrote:I did post the bug that I promised a couple of posts back for all the good it did (Bug # 145430) I just got it back with a "Resolved Invalid" stamp on it. I got this reply from the Dev, who seems to think it isn't necessary to recompile the system, though he didn't explain his reasoning or exactly what he thought SHOULD be done...
as for having to recompile world, that's complete garbage

Spanky didn't say to not recompile system. He said recompiling world isn't necessary.

And as far as I understand, he is technically right since the world recompile is only necessary to make use of the new compiler for all your userland apps. But please correct me if I'm wrong about that one.

mark_alec · Post by **mark_alec** » Tue Aug 29, 2006 11:11 am

I believe SpanKY is saying that there is no need to recompile world when you update glibc, he is not talking about upgrading gcc (follow the doc for that).

Gergan Penkov · Post by **Gergan Penkov** » Tue Aug 29, 2006 1:30 pm

loki99 wrote:
Gooserider wrote:I did post the bug that I promised a couple of posts back for all the good it did (Bug # 145430) I just got it back with a "Resolved Invalid" stamp on it. I got this reply from the Dev, who seems to think it isn't necessary to recompile the system, though he didn't explain his reasoning or exactly what he thought SHOULD be done...
as for having to recompile world, that's complete garbage
Spanky didn't say to not recompile system. He said recompiling world isn't necessary.

And as far as I understand, he is technically right since the world recompile is only necessary to make use of the new compiler for all your userland apps. But please correct me if I'm wrong about that one.

The only problem I see is how good they have fixed the fix-libtool-files script, which caused the majour damages from what I have read here in the forums (and emerge -e world will correct them), other than that probably revdep-rebuild for the c++-api should suffice - although I'm not completely sure about this.

wolf31o2 · Post by **wolf31o2** » Tue Aug 29, 2006 8:55 pm

Here's the thing... revdep-rebuild will *not* work because they changed the ABI in subtle ways without a .so bump. This means that things will break, though only a few things. The only truly *safe* method is to use emerge -e system to upgrade your toolchain, then emerge -e world, to update your userland. You *could* skip the emerge -e world and just let things recompile on their own, but there's still the possibility of bugs being introduced because of this. To be honest, the revdep-rebuild option should have never been mentioned for the 3.3->3.4 upgrade, except that it is actually valid in that case. Preferable, would have been to force a complete recompile, like for 4.1, with 3.3->3.4 also.

The only real safe option is a rebuild of system, then world. Feel free to ignore me, though. It's your system. However, we don't just make these recommendations to make them. We have good reason.

swimmer · Post by **swimmer** » Tue Aug 29, 2006 9:15 pm

Ahhhh - this is the beef!!!

Shouldn't this information flowing in the GCC Update Guide as well? Not as raw, but hey - it's beef

Greetz
swimmer

Gooserider · Post by **Gooserider** » Tue Aug 29, 2006 11:04 pm

Well, perhaps it is because I'm jumping the gun and not waiting for the GCC / GLIBC files to go stable, but...

Loki99
You seem to missunderstand. There will be no need to mention it explicitly, since glibc automatically gets updated when you follow the instructions from the GCC update guide. The appropriate glibc will be made stable when gcc-4.1.1 becomes stable so there will be no need to unmask it.

Well, what seemed strange, which is why I started raising the question, is that when I emerged GCC, I did NOT see it pull down the GLIBC with it.
There were a couple of other libraries that Portage wanted to pull down, but not GLIBC. I also didn't see GLIBC listed among the files when I started doing the "emerge -eav system". I'll admit I didn't watch it every minute

but it didn't pull down the new GLIBC that I saw.

As further evidence, my observation has been that Portage doesn't pull down a file if you already have it (and haven't changed use flags or other stuff that would make it need to do a recompile) but once I unmasked it, portage did pull down the new sys-libs/glibc-2.4-r3, and showed it as a NEW file. (OTOH, just now when I repeated the command that got it for me last time, it said I had zero bytes to d/l)

Thus, AS CURRENTLY WRITTEN, following the GCC General Upgrade procedure apparently does NOT

upgrade the library, at least not as far as I've gotten in the procedure. According to my bash history, I've followed the process as given up through re-compiling system, but not world.

Given that, I assume that I need to do something to get the box to use the new GLIBC, but I'm not sure just what. Any Ideas

And if you are running testing, you are expected to know what you are doing.

It does help doesn't it?

I consider myself an intermediate level user, not a guru, and as such, I generally don't try to do testing level stuff. I went for this because I read that it was about to become a reccomended procedure, and wanted to get it over with before I downloaded any additional packages and thus made the process even longer. If you look back in the thread, you'll notice that I was very nervous about this, and asked several times about 'gotchas' in the process. I was repeatedly reassured by people who's tags should have indicated that they did know what they were talking about, that it was a straightforward matter of just following the instructions... When I tried to do that, I found a few holes (like this one).

Gooserider

Dralnu · Post by **Dralnu** » Tue Aug 29, 2006 11:08 pm

If you unmask gcc and glibc at the same time, they both will be fixed when you emerge -e system/world. I think thats what he was refering to

Gergan Penkov · Post by **Gergan Penkov** » Tue Aug 29, 2006 11:15 pm

wolf31o2 wrote:Here's the thing... revdep-rebuild will *not* work because they changed the ABI in subtle ways without a .so bump. This means that things will break, though only a few things. The only truly *safe* method is to use emerge -e system to upgrade your toolchain, then emerge -e world, to update your userland. You *could* skip the emerge -e world and just let things recompile on their own, but there's still the possibility of bugs being introduced because of this. To be honest, the revdep-rebuild option should have never been mentioned for the 3.3->3.4 upgrade, except that it is actually valid in that case. Preferable, would have been to force a complete recompile, like for 4.1, with 3.3->3.4 also.

The only real safe option is a rebuild of system, then world. Feel free to ignore me, though. It's your system. However, we don't just make these recommendations to make them. We have good reason.

Well this means that the docs should be changed and revdep-rebuild left out of the game for good, as otherwise this will bring flood of bugs around and a lot of whining in the forums.
I know how long could it take to emerge -e system && emerge -e world, especially on old computers, but at least at the end you know that the system is working and one does not have to waste time coping with different stange "problems" afterwards.

Gooserider · Post by **Gooserider** » Wed Aug 30, 2006 2:22 am

Dralnu
If you unmask gcc and glibc at the same time, they both will be fixed when you emerge -e system/world. I think thats what he was refering to

I'm not sure if that would have worked - when I unmasked GCC, it did NOT complain about GLIBC, though it DID ask me to unmask another library (dev-libs/gmp-4.2.1) as well as one or two others that it upgraded but which weren't masked.

I'm guessing that I need to go back in the GCC Upgrade process, but I'm not sure just how far back -

Do I need to go back to:
# gcc-config i686-pc-linux-gnu-3.4.5
or:
# source /etc/profile
or do I just need to:
(Rebuilding libtool)
# emerge --oneshot -av libtool

Or is there some additional step that I need to take to tell GCC to use the new glibc 2.4-r3??

Gooserider

Dralnu · Post by **Dralnu** » Wed Aug 30, 2006 2:50 am

If you unmask/unkeyword glibc 2.4, then you just need to recompile the system to use it unless I'm mistaken. I'm upgrading glibc right now myself.

If someone knows anything we're missing here, please mention it

menschmeier · Post by **menschmeier** » Wed Aug 30, 2006 8:41 am

Hi,

I would like to upgrade to gcc 4.1.1 too. The upgrade process seems not to be that difficult if http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_4.1 is true.

But I found on http://gentoo-wiki.com/TIP_Testing_GCC_4.1 that openoffice might not be compiled.

Does anyone notice this behaviour? I am using app-office/openoffice-2.0.3. I could surround this problem by using the binary package.

Can someone tell me which programms are not able to compile or run with gcc 4.1.1?

Thanx
menschmeier

Q-collective · Post by **Q-collective** » Wed Aug 30, 2006 9:12 am

menschmeier wrote:Hi,

I would like to upgrade to gcc 4.1.1 too. The upgrade process seems not to be that difficult if http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_4.1 is true.

But I found on http://gentoo-wiki.com/TIP_Testing_GCC_4.1 that openoffice might not be compiled.

Does anyone notice this behaviour? I am using app-office/openoffice-2.0.3. I could surround this problem by using the binary package.

Can someone tell me which programms are not able to compile or run with gcc 4.1.1?

Thanx
menschmeier

OpenOffice compiles for me.
Gcc 4.1.1 installed.

amne · Post by **amne** » Wed Aug 30, 2006 9:25 am

Gooserider, glibc will be marked stable at the same time as gcc 4.1. This is a normal update, so there is no need to mention it in the upgrade guide for gcc, because it has nothing particular to do with it. As soon it goes stable, portage will update it anyway, either by using emerge -u world or -e world (whatever you do first, and you're supposed to emerge -e world anyway after the gcc upgrade at which time glibc will be stable).
If you want to unmask those packages before they go stable, you really should know what you are doing - otherwise just wait.

As for the updates to the gcc upgrade guide, i've already opened a bug report about it, hope someone is able to fix it soon.

menschmeier · Post by **menschmeier** » Wed Aug 30, 2006 10:56 am

Hi,

I am now in the process of updating gcc to version 4.1.1.

On http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_4.1 ist written that I have to run

Code: Select all

emerge -e system

twice. But this something I do not understand.

So I already have gcc-4.1.1 and configured a default compiler. After runing 'emerge -e system' all programms in system should be rebuilt - even gcc itself. Why run "emerge -e system' again?

Any hints for me?

menschmeier

CRV§ADER//KY · Post by **CRV§ADER//KY** » Wed Aug 30, 2006 11:10 am

menschmeier wrote:Any hints for me?

menschmeier

read the topic before posting

Paapaa · Post by **Paapaa** » Wed Aug 30, 2006 11:17 am

menschmeier wrote:So I already have gcc-4.1.1 and configured a default compiler. After runing 'emerge -e system' all programms in system should be rebuilt - even gcc itself. Why run "emerge -e system' again?

Any hints for me?

Yes, start using the official documentation

There should be no need to emerge system twice. This confusion was mostly (I guess) because some people thought that GCC needs to be rebuild again with itself to ensure proper functionality. This is false, because GCC actually compiles itself 3 times in a row (alaways using the compiled compiler) to ensure that the result doesn't depend on the previous version. Only one system rebuild should be enough.

menschmeier · Post by **menschmeier** » Wed Aug 30, 2006 11:34 am

Hi Paapaa,

Paapaa wrote: Yes, start using the official documentation There should be no need to emerge system twice. This confusion was mostly (I guess) because some people thought that GCC needs to be rebuild again with itself to ensure proper functionality. This is false, because GCC actually compiles itself 3 times in a row (alaways using the compiled compiler) to ensure that the result doesn't depend on the previous version. Only one system rebuild should be enough.

My problem was that I read several docs, some on gentoo-wiki.com, for me theese wikis seems to be very reliable, but in this point they caused some confusions. I ecpect http://www.gentoo.org/doc/en/gcc-upgrading.xml to be the "official" documentation. There is clearly written that an 'emerge -e system' and 'emerge -e world' is necessary only one time - and they should it know.

Thanx for your support.

menschmeier

Dominique_71 · Post by **Dominique_71** » Wed Aug 30, 2006 11:35 am

menschmeier wrote:Hi,

I would like to upgrade to gcc 4.1.1 too. The upgrade process seems not to be that difficult if http://gentoo-wiki.com/HOWTO_Migrate_to_GCC_4.1 is true.

But I found on http://gentoo-wiki.com/TIP_Testing_GCC_4.1 that openoffice might not be compiled.

Does anyone notice this behaviour? I am using app-office/openoffice-2.0.3. I could surround this problem by using the binary package.

Can someone tell me which programms are not able to compile or run with gcc 4.1.1?

Thanx
menschmeier

I don't know all the CFLAGS used in the Tip_Testing_Gcc wiki, bit I know at open office is very sensitive in that matter. As exemple, it will not compile if Python was compiled with -ffast-math.

About this CFLAGS problem, I have glibc-2.4 but still have gcc-3.4.6, because more I search about the new CFLAGS introduced with gcc-4, more I read contradictory repports. For now, I have gcc 3.4.6):

Code: Select all

CFLAGS="-O3 -march=pentium4 -pipe -fomit-frame-pointer -fforce-addr -fno-ident -ftracer"
CXXFLAGS="${CFLAGS}"
LDFLAGS="-Wl,-O1 -Wl,--sort-common"

I am planing to get back to -O2, because at even if I am able to compile and run everything, even ooffice and any LADSPA plugins with those flags, the -fforce-addr correct the missbehaviour of -O3 with some functions, but the resulting code is not faster as with -O2 alone and it is still bigger and take more time to compile. So it is not worth to use -O3. With -O3 and without -fforce-addr, even when the programs did compile, they run faster, but I get buggy code with some programs, and I don't have the time to test the CFLAGS for all my installed programs.

So, my question is: Is it somewhere a thread or an explanation about those new use flags? As exemple, I think at something as:

Code: Select all

CFLAGS="-O2 -march=pentium4 -pipe -ftracer -fweb -ftree-vectorize"

or

Code: Select all

CFLAGS="-march=pentium4 -O2 -pipe -fomit-frame-pointer"

and the same CXXFLAGS ans LDFLAGS as before can be just fine. But I am not sure. I read at the -ftree-vectorize does wonders. It is for loop optimisation, and I read on the IBM website at it can be a 20 time speed improvment (Yes, twenty, it is no misspelling here.), but I read elsewhere at all depend of the size of the loop. It will be an increase with big loop, but the additionnal structural code will make the compiled program slower with small loop. So I am lost.

The most important use for my computer are audio and electronic simulation. Each of those aera use code with many mathematical functions, it mean code with loops. So I think at the -ftree-vectorize function will be good to have in this case, but I want too to be able to compile other program as oofice and still have a stable system. Is it a link on a understandable discussion on that matter?