| Summary: | toolchain.eclass doesn't properly set S | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Brian Harring (RETIRED) <ferringb> |
| Component: | New packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | dev-portage |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
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" |
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.