On 10/12/2012 4:03 AM, Gregory M. Turner wrote:
First, something puts in all kinds of inappropriate amd64 multilib paths
(this ends up being harmless as wrong-arch libraries get rejected at
link-time and treated as non-matches for -lclauses... still, WTF?).
Secondly, something puts the built-in ld search paths into the
command-line ld search path (a practice which has been roundly
disparaged in this thread, and correctly so, IMO).
Thirdly, prefix x86-linux also clearly suffers from the original problem
I was seeing in cygwin, and which inspired this thread (putting -L.
after $(libdir) paths and therefore linking against the wrong
libpython.so). I never suspected this applied to every prefix python
ebuild, but that's what the above seems to suggest... not cool.
Just wanted to update this thread with latest current triage and
prognosis data for this patient:
Regarding etiology, for "Firstly" and "Secondly" above: it seems that
these are by design (which is not to say that they should be left: in
each case, the "design" is pretty bad and ought to be fixed, I think).
My hope is that "Firstly" and "Secondly" are needed only to accommodate
prefix bootstrap, in which case we can fix them by detecting whether a
prefix bootstrap is ongoing or not, and conditioning these hacks on that
(improving "Firstly" to not be braindead would be a nice touch, although
doing so in a way that doesn't break anything may be prohibitively
difficult or beyond my abilities).
"Thirdly" has been addressed ad nauseam in this thread and will be
solved by prepending the LDFLAG rather than appending, or, preferably,
by patching autotools (but only if I can find a simple, low-maintenance
approach that is likely to work without building any new per-platform
matrices or case-statements).
Note that, even without this third fix, absent a PEBKAC placement of
"-L${EPREFIX}/usr/$(libdir)" into LDFLAGS, either:
o it's a prefix bootstrap, in which case there probably is no
${EPREFIX}/usr/$(libdir)/libpython${PV}.so, or
o it's /not/ a prefix bootstrap, in which case the above-mentioned
fixes would prevent the "-L${EPREFIX}/usr/$(libdir)" from
getting into LDFLAGS, thus preventing the problem from arising.
So by fixing "Firstly" and "Secondly," we have at least brought things
sufficiently in line with expectations that we are only fixing
user-level configuration mistakes instead of our own, as originally
expected. **
I'm feeling ready, at this point, to file bugs for these issues; once I
do, I'll post bug#'s into this thread and plan to take all off this
chatter off-list, unless something more comes up that seems to require
community review.
Thanks for everyone's help figuring this stuff out,
-gmt
** I suppose a third possibility is that someone is doing an in-place
"re-bootstrap" or restarting a bootstrap build that failed mid-merge,
but ... doesn't matter, it'll be academic once we fix the bug.
