On 10/11/2012 8:50 AM, Mike Frysinger wrote:
On Thursday 11 October 2012 05:35:21 Gregory M. Turner wrote:
On 10/10/2012 9:14 PM, Mike Frysinger wrote:
it's not particularly important, but on one hand, the LDFLAGS parsing logic
should not be in the tree ever.
I've no major attachment to it. Took all of five minutes to code up
reading the ld manpage, and as you pointed out, it's probably solving a
non-problem.
on the other, i can stomach much smaller one-
off hacks like prepending -L. to LDFLAGS if the maintainers of the python
ebuild really really want to add it.
If fixing the python builds proves too onerous then this is what I'll
end up filing a bug for.
my [limited] understanding of the prefix compiler is that they wrap things with
a custom shell script to inject -L flags behind the back of the compiler at the
very last possible minute and point to the right place.
Pretty fuzzy on this myself. Whatever binutils-config does works so
well I've never had to look into it very deeply :)
Above, however, I'm referring to the prefix-specific cpython patch-sets,
where I was "sure" I'd seen patches to project LDFLAGS into setup.py's
compiler invocation tables. But it seems I was mistaken. Perhaps it
was in the main gentoo-patches after all... or maybe I just need more
coffee...
Anyhow one thing I have figured out is how things can work correctly on
Linux wihtout -L.: on Linux, the python plugins aren't actually linked
against libpython.so!
With any luck, this explains what's going on and suggests that platforms
linking python modules against libpython.so just need to wedge -L${S}
somewhere in configure.in, possibly do-able via sed script (unless we
end up having to mess with setup.py, in which case, things may get a bit
more complicated).
-gmt
