This one took a *massive* amount of time to find... so pardon if I sound pissy :) Essentially, I suggest y'all take a look at what S is set to after the setup phase for gcc-3.4.3.ebuild. Current portage is sloppy about env saving/restoring, whats cooking in cvs isn't however- variables (and their attributes) *are* saved and restored for all phases. Basically, all of your ${S:=$(gcc_get_s_dir)} doesn't fly. Set it once, instead of trying to ensure it's set the entire way. This needs to be addressed- post .51 versions of portage *will* not work with this lazy setting of S, as portage-cvs demonstrates now. If you wish to not set S in the global scope, fine, do it in setup. Just don't keep attempting it on the fly.
err... what exactly is the problem? that sounds kinda.... well. broke. on the portage side of things. can you explain just a little bit more? i'm not against fixing it, i'm just confused here about why it needs fixing. you havent told me anything. that is, i dont see why ${variable_if_set:=get_value_if_not_set} would ever cause problems. you -will- get the same result there whether S is set or not, no?
wait... i DO set S in the global scope of the ebuilds. what are you talking about?
Just updating the bug with the info from irc- you do set S, but it is invalid. gcc_get_s_dir is dependant on gcc_setup_static_vars having been run, which isn't (at that point at least).
fixed in toolchain.eclass
I recall telling you this when you were first implementing the toolchain.eclass :P "<lv> It works for me"
