Re: [gentoo-dev] Re: [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath

[Gregory M. Turner]

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