| Summary: | directory $EPREFIX$EPREFIX is created during emerging odcctools | ||
|---|---|---|---|
| Product: | Gentoo/Alt | Reporter: | MATSUI Tetsushi <VED03370> |
| Component: | Mac OSX | Assignee: | osx porters <osx> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | zmedico |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | OS X | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
MATSUI Tetsushi
2008-01-06 15:43:48 UTC
Thank you VERY much for finding this. The cause is binutils-config, which sets ROOT to ROOT/EPREFIX, and hence causes the double prefix as portage returns and tries to do stuff. odcctools ebuild (binutils for Darwin) runs in pkg_config binutils-config to set the new linker. binutils-config itself changes ROOT when set into an absolute path if relative. In prefix, binutils-config also adds EPREFIX to ROOT, to cheaply get prefix support from binutils-config. @zmedico: is it possible to "protect" Portage from picking up this changed variable. ROOT is quite important (so are other vars) and when modified in called code, should IMO not affect Portage, e.g. it should be immume for changes to it (does it make sense?). Would it make sense to declare ROOT as a read-only variable, like P, PN, etc.? (In reply to comment #1) > @zmedico: is it possible to "protect" Portage from picking up this changed > variable. ROOT is quite important (so are other vars) and when modified in > called code, should IMO not affect Portage, e.g. it should be immume for > changes to it (does it make sense?). > > Would it make sense to declare ROOT as a read-only variable, like P, PN, etc.? The drawback of declaring variables readonly is that it makes it impossible to ebuilds to override them as local variables when necessary. For example, the gimp ebuild declares AA as an empty local variable in src_compile in order to prevent the real value from interfering with econf. When we make variables readonly, ebuilds need something like the env command if they want to do a local override for some reason. Because of issues like this, I prefer not to make variables with short names like ROOT readonly since ebuilds may need to override them locally. Of course, it it was something like PORTAGE_ROOT then in wouldn't be an issue because ebuilds would almost certainly never need to override it locally. Thank you very much again. I fixed binutils-config appropriately and bootstrapping completely from scratch appears not to have the double prefix any more. |
