Stage 1/3 Installation Support - Gentoo 2004.3 & GCC 343

[Master One]

Well, I am still stuck with my KDE3.4.0_rc1 problem, and I think I need some clearification:

So I used Bob P's brilliant "Stage1 on a Stage3 Tarball" installation menthod, and I used the full set of the mentioned "bleeding edge" CFLAGS+CXXFLAGS+LDFLAGS.

Everything compiled just fine on that machine, except ~ 18 packages of KDE3.4.0_rc1, which simply do not want to compile. These packages are all some kind of "media" related, and the error-output is pretty similar, please see this thread.

The question is now, how I should proceed, if I want to try it with more "sane" flags on those packages again.

Is it possible, that the toolkit itself got damaged by my flags-selection, when compiling the toolkit in the first place? This would be the only explaination, why the error stayed the same with those ~ 18 KDE3.4.0_rc1 packages, independently of the flag-selections, I tried on those packages. If this should really be possible, it looks like the only way to fix it, would be to recompile the whole toolkit with "saner" flags, right?

On the other hand, if everything else is just working fine, can't it be, that only gcc-3.4.3 has a problem?
Wouldn't it be enough then, to just recompile either gcc-3.4.3, or the last "x86" gcc-version (3.3.5-r1) with a "saner" flags-selection, and then try either or both of these recompiled gcc-versions?

P.S. I think I really get confused with this stuff now. On one hand, I understand the purpose of a properly compiled tookkit, which is the main purpose of Bob P's guide, on the other hand I don't understand, how easy gcc-switching using gcc-config should be possible, if it always comes down to the whole toolkit. Can someone enlighten me, please?

[96140]

That's what I've heard; that gcc 3.4.3.x itself simply does not work on KDE 3.4; it's too broken just yet. Might want to give it a week or so and see what develops.

[Master One]

That's what I've heard; that gcc 3.4.3.x itself simply does not work on KDE 3.4; it's too broken just yet. Might want to give it a week or so and see what develops.

I'm still searching for more info on that issue. Until now, noone could confirm, that it's not possible to compile KDE3.4.0_rc1 with gcc-3.4.3-20050110, so I am still unsure, if it is my compile-flags-selection, or simply gcc-3.4.3-20050110 itself.

If it's 3.4.3-20050110 itself, causing those troubles (or the other way: if it's KDE3.4.0_rc1 causing those troubles with gcc-3.4.3-20050110), shouldn't it be possible, to switch to 3.3.5-r1 or 3.3.4 (just using gcc-config, to whatever version else is installed on your system), and to compile the remaining ~18 packages with that compiler-version?

[corefile]

Strange thing is, I don't have a /boot/grub directory when I reboot, but during the boot process there is a grub screen and everthing works fine. I went to take a look at something and cd /boot and there is no grub directory. what gives

[96140]

Strange thing is, I don't have a /boot/grub directory when I reboot, but during the boot process there is a grub screen and everthing works fine. I went to take a look at something and cd /boot and there is no grub directory. what gives

Take a look at your /etc/fstab: I'm willing to bet that if you followed this guide exactly, you copied Bob P's fstab, and have set /boot to not be mounted automatically. If you want to be able to freely browse /boot, remove "noauto" from its options; instead, just have it set to "notail", the way / is supposed to be configured.

See, the boot process of course goes to /boot to load up the kernel and such, but that doesn't automatically make it available to you once the system is booted; you have to manually mount it yourself if you have "noauto" specified.

[corefile]

Dang, I tried to repost before someone reponded. It was the first thing I checked, that was it.
Thanks for the help, now I'm off to go read why one would not want to have /boot mounted (sorry I'm use to rhat) Again thanks for the response.

[Infra]

Hi,

Anyone tried if this install method works for the AMD64-platform? Of course there has to be few changes to be done but mostly it should work right?

[kimchi_sg]

Hi,

Anyone tried if this install method works for the AMD64-platform? Of course there has to be few changes to be done but mostly it should work right?

Why don't you be the first to try?

[Infra]

Hi,

Anyone tried if this install method works for the AMD64-platform? Of course there has to be few changes to be done but mostly it should work right?

Why don't you be the first to try?

I will, when i get my next server.

[Bob P]

So I used Bob P's brilliant "Stage1 on a Stage3 Tarball" installation menthod, and I used the full set of the mentioned "bleeding edge" CFLAGS+CXXFLAGS+LDFLAGS.

Everything compiled just fine on that machine, except ~ 18 packages of KDE3.4.0_rc1, which simply do not want to compile.

fwiw, i use a more "sane" set of cflags when I compile kde or any of its components. i revert to the CFLAGS that are in the first post; that is to say, i don't use kimchi-sg's recommended flags when compiling kde, i use no entry for cxxflags, and i use no ldflags. taking that approach, i've had no problems whatsoever with kde 3.3.x with gcc 3.4.3.20050110.

of course, i have no idea whether my 20050110 is the same 20050110 that is in portage right now, as i locked down my toolkit prior to all of that masking/unmasking business with 3.4.3-r1 and 20050110. its entirely possible that something is different in the version of 20050110 that's now in the portage tree, and that my results just can't be reproduced because the compiler has been somehow changed.

The question is now, how I should proceed, if I want to try it with more "sane" flags on those packages again.

Is it possible, that the toolkit itself got damaged by my flags-selection, when compiling the toolkit in the first place? This would be the only explaination, why the error stayed the same with those ~ 18 KDE3.4.0_rc1 packages, independently of the flag-selections, I tried on those packages. If this should really be possible, it looks like the only way to fix it, would be to recompile the whole toolkit with "saner" flags, right?

fwiw, i have decided to stay away from KDE in the testing branch. i've reverted to stable branch kde 3.3.x on all of my boxen, because the kde ebuilds are just too damned big to keep recompiling every time that one little component gets changed. as much as i like the kde interface, compiling kde is a major league PITA -- i hate it.

i'm completely baffled about what kind of advice to give for you guys who are brave enough to try out the kde betas. i'm sure that the idea of split ebuilds is the greatest thing since sliced bread, but based on my bad experiences with kde and cflags in the past, i'm very reluctant to even use the testing branch any more. you guys that have jumped in with both feet and are using kde betas are much braver than i am.

so even though the new kde offers split ebuilds and is reportedly more cflag-friendly, i just can't bring myself to go into the kde beta branch. fwict the ebuilds just aren't reliable.

by any chance, have you thought about blazing the trail, and trying to build a system based on gcc 4.0? it would be interesting to try the kde betas with that. my impression is that you'll be more successful with 4.0 than 3.3.4.

[Master One]

fwiw, i use a more "sane" set of cflags when I compile kde or any of its components. i revert to the CFLAGS that are in the first post; that is to say, i don't use kimchi-sg's recommended flags when compiling kde, i use no entry for cxxflags, and i use no ldflags. taking that approach, i've had no problems whatsoever with kde 3.3.x with gcc 3.4.3.20050110.

The problem seems to be, that just reverting to a minimal and very safe set of flags just does not help in that case, I got it down to "-O2 -pipe" without additional CXXFLAGS & LDFLAGS, but it led to the exact same error on those packages, which led me to the conclusion, that it has to be a gcc-3.4.3-20050110 vs KDE3.4.0_rc1 issue, since it can't be my gcc / toolkit to be broken (otherwise I surely would have discovered much more problems with other packages as well, I assume).

of course, i have no idea whether my 20050110 is the same 20050110 that is in portage right now, as i locked down my toolkit prior to all of that masking/unmasking business with 3.4.3-r1 and 20050110. its entirely possible that something is different in the version of 20050110 that's now in the portage tree, and that my results just can't be reproduced because the compiler has been somehow changed.

I think, it is the same version as you have installed, they surely would not have changed anything with letting the version number the same (and there is only one gcc-3.4.3-20050110).

fwiw, i have decided to stay away from KDE in the testing branch. i've reverted to stable branch kde 3.3.x on all of my boxen, because the kde ebuilds are just too damned big to keep recompiling every time that one little component gets changed. as much as i like the kde interface, compiling kde is a major league PITA -- i hate it.

I think I also stop playing arround with KDE3.4.0_rc1, I need a working environment, so I am going to install 3.3.2-r1 for now, and wait for the upgrade to 3.4.0, until it has entered the stable branch.

by any chance, have you thought about blazing the trail, and trying to build a system based on gcc 4.0? it would be interesting to try the kde betas with that. my impression is that you'll be more successful with 4.0 than 3.3.4.

An interesting idea, to try out gcc-4.0.0_alpha20050213. Do you think it is enough, just to emerge this gcc-version, and to switch using gcc-config?
I am still confused about the need, to recompile the whole toolkit after one part of it has changed, since the rest stays the same and is already compiled correctly, using your advanced install method.

[JensRex]

Why have both -march and -mtune in the CFLAGS? To quote from the GCC documentation:

specifying -march=cpu-type implies -mtune=cpu-type

[UgolinoII]

An interesting idea, to try out gcc-4.0.0_alpha20050213. Do you think it is enough, just to emerge this gcc-version, and to switch using gcc-config?
I am still confused about the need, to recompile the whole toolkit after one part of it has changed, since the rest stays the same and is already compiled correctly, using your advanced install method.

Im hacking my way through converting my desktop to use nptl with 3.4.3 from a "gcc3.3.5 + non-nptl" state.

From what I've gleaned on the variuous threads on this I would suspect that th point of re-emerging the toolkit, is so that the toolkit itself has been compiled with the latest gcc available, so that it is taking advantage of the optimisations. (Equally having emerged gcc i think you then need to re-emerge it once you've switched via gcc-config. What better test for a compiler than compiling itself )

The whole theory to me seems very straightfoward, change headers, change your make.conf, build your new compiler&toolchain, then you switch via gcc-conf and use your new c&tc to rebuild your c&tc, then your rebuild everything else. Maybe I'm missing something (im thinking it seems easy maybe because Im not building a box from scratch)?

The proof of the pudding will be when i try rebooting once i've done all this

I have a bunch of old bits (barring a box) which im planning to knock together a mail server from, I think it would be a prime opportunity to jump into gcc-4 land!

[Bob P]

in my case, because i often compile on one cpu-type for deployment upon another cpu-type.

[96140]

Why have both -march and -mtune in the CFLAGS? To quote from the GCC documentation:

specifying -march=cpu-type implies -mtune=cpu-type

You need to read things like this, and then pages 11, 12, and 13 of the install guide to get an idea of why both are specified. One of the reasons for using -march is because gcc 3.3.x doesn't support -mtune, but gcc 3.4.3.x does. And, as some ebuilds don't use -march, then using -mtune gets in a few processor-specific optimizations. -mtune isn't as good as -march, but one can actually use -mtune and -march to describe two different processor functions.

I recall reading very recently somewhere two different uses of this; one was to figure out how to deal with tricky -march settings for a Pentium M; the solution was to use instruction sets from one kind of processor and the capabilities of a P4. Another problem was solved by using an Athlon profile while also adding in specific capabilities it shared with an Intel chip, just to make sure things like SSE and 3Dnow! are used when possible during compile. So you could have -march=pentium3 and -mtune=pentium4, for example, if both described your chip. Typically though, unless you're running something a little more exotic like a Pentium M, Celeron, or odd flavor of Athlon, your -march and -mtune flags will be identical. Search the forums for more information, if you really want to know.

[corefile]

of course, i have no idea whether my 20050110 is the same 20050110 that is in portage right now, as i locked down my toolkit prior to all of that masking/unmasking business with 3.4.3-r1 and 20050110. its entirely possible that something is different in the version of 20050110 that's now in the portage tree, and that my results just can't be reproduced because the compiler has been somehow changed.

Bob what do you mean you locked down your toolkit? Is there anytheng we need to do after we get everything working to lock it down? Or are you just using that as a frame of speech to say that you got your stuff working so you don't mess with it? By the way thanks for guide.

[moltas]

Hello
I need help to finde the locales.buid for sweden.
Downt no how to finde it.
Thanks

[JensRex]

[valid reasons for using -march and -mtune]

Thank you for the explanation. I appreciate it, and I will take it into consideration.

I'm not one who just blindly copies CFLAGS from all over the place. I like to know exactly what each setting does, and why it needs to be there, as well as what possible advantages and drawbacks are associated.

[Bob P]

I think, it is the same version as you have installed, they surely would not have changed anything with letting the version number the same (and there is only one gcc-3.4.3-20050110).

although it might seem counter-intuitive, the devs update ebuilds without changing their version numbers all of the time. throughout all of the masking/unmasking of the GCC 3.4.3 compilers, the actual ebuillds went through a number of revisions although their version numbers never changed.

[Bob P]

Bob what do you mean you locked down your toolkit? Is there anytheng we need to do after we get everything working to lock it down? Or are you just using that as a frame of speech to say that you got your stuff working so you don't mess with it? By the way thanks for guide.

we talked about locking down the toolkit in the other thread. rather than retyping things, i'll just direct you there.

[corefile]

Bob which thread, your original thread on stage1 on stage3, NPLT thread? Is it part of the instructions?

thanks

[Master One]

Well, just an update for those, who care:

After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:

Code: Select all

CFLAGS="-O2 -march=pentium-m -pipe -fforce-addr -fomit-frame-pointer -fweb"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1"

The clue is, these few flags most likely will give a much better results, than the formerly used stacked "insane" flags.
I now see the sense of going -O2 instead of -O3, at least one of the "insane" flags had questionable results (-fprefetch-loop-arrays -> "These options may generate better or worse code"), and one definitely broke libs without error on compile (-fvisibility=hidden -> only to be used by developers, at least for now).

I compiled my whole system with these save set of flags, started right from the beginning with Bob P's fabulous installation method, and at the moment I am emerging KDE 3.3.2-r1 (I keep staying on the stable side now, and let others do the KDE3.4.0_rc1 testing).

This time everything looks alright.

[Bob P]

Well, just an update for those, who care:

After taking some time to study the gcc onlinedocs, I reverted to the following save set of flags for my IBM ThinkPad T42p:

Code: Select all

CFLAGS="-O2 -march=pentium-m -pipe -fforce-addr -fomit-frame-pointer -fweb"
CXXFLAGS="${CFLAGS} -fvisibility-inlines-hidden"
LDFLAGS="-Wl,-O1"

The clue is, these few flags most likely will give a much better results, than the formerly used stacked "insane" flags.
I now see the sense of going -O2 instead of -O3, at least one of the "insane" flags had questionable results (-fprefetch-loop-arrays -> "These options may generate better or worse code"), and one definitely broke libs without error on compile (-fvisibility=hidden -> only to be used by developers, at least for now).

to reach a high degree of success on a wide variety of platforms, i think that its important to be selective about one's choice of cflags. fwiw, i'm still not using the insane set of cflags on my system. i'm still limiting myself to the conservative and performance-enhancing cflags that i've used in the Guide. although the use of some of those other flags (suggested by kimchi-sg) may be alluring, its important to remember that they can act as a double edged sword. some of them cause alot of problems -- more problems than they are worth.

i don't use -funroll-loops, for example. that flag has acquired a deservedly bad reputation. -fprefecth-loop-arrays is another one.

i've said it before, and i'll say it again:

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: Select all

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

If you don't feel comfortable using such extreme levels of optimization, you can ease-up on the CFLAGS settings and fall back to a less-optimized system. This will save you some compile time, at the expense of some system performance. You'll still be getting most of the benefits of GCC 3.4.3, so this isn't a bad compromise. This may be a better approach for those who don't want to be on the bleeding edge or don't want to spend time troubleshooting.

Code: Select all

CFLAGS="-O2 -march=pentium -mtune=pentium -pipe" 
CXXFLAGS=${CFLAGS} 

these cflags are conservative. they are extensivley tested and they are proven to be safe. in the Guide, i have specifically warned people about the need for troubleshooting that would result from using anything other than the recommended flags. kimchi_sg also made his warnings in bold faced red type. its really surprising to me that in spite of repeated warnings, people decide to use flags other than those that are recommended. its as if there's some overpowering vortex that is pulling everyone into the land of the Gentoo Ricer. not that there's anything wrong with that, of course, as long as the user is willing to accept the responsibility for troubleshooting their own system. unfortunately, that kind of trouble is going to follow for those that insist on adding to the cflags. the funny thing is that the problem is completely avoidable, but people just can't seem to resist the temptation to subject themselves to it.

my personal recommendation is to stick with the cflags that are recommended in the guide. when i wrote the guide, i tested those cflags extensively on a wide variety of PCs. i performed a large number of installations, and i got rid of cflags that caused problems. if the user is going to try out cflags other than those that are listed, they should expect to encounter problems that will require troubleshooting.

[dellaxim]

Hi Bob,
Thanks you very much for the detail and clear HOWTO

I succeeded install stage 1 on 3 on my machine but I think I stuck with some problems with the compiler.
If I leave the CXXFLAGS as in tutorial, I cant emerge any package, it return

Code: Select all

  Function econf,  Line 485 exit code 0 

But if I go back and set the CXXFLAGS to "short" it compile fine.

Thanks you!

[dellaxim]

One more problem I noticed,
When I try to compile mplayer, it returns the following error

Code: Select all

Error: Bad gcc version

Check "configure.log" if you do not understand why it failed.

!!! ERROR: media-video/mplayer-1.0_pre5-r5 failed.
!!! Function src_compile, Line 460, Exitcode 1
!!! (no error message)
!!! If you need support, post the topmost build error, NOT this status message.

So i guess it is the problem from gcc 3.4.3.
My 2 cents
Thanks