On Thursday 11 October 2012 05:35:21 Gregory M. Turner wrote: > On 10/10/2012 9:14 PM, Mike Frysinger wrote: > > On Wednesday 10 October 2012 23:37:26 Gregory M. Turner wrote: > >> (1) is worse than (2), but it does have some quasi-legitimate usages. > >> For example, prefix bootstrap does this (or used to), as do many of the > >> crossdev-wrapper scripts. I've also resorted to such usage, myself, > >> when repairing a prefix after I've broken its compiler. These cases > >> don't really seem completely "correct" or "incorrect" -- about the best > >> I can say for them it is that they are mostly efficacious, but prone to > >> problems. > > > > and no, crossdev doesn't do this. it is properly sysrooted. > > You are right. I guess I was thinking of this: > > http://tinderbox.x86.dev.gentoo.org/misc/cmerge, > > Which does use -L but looks pretty ancient. I see now that crossdev's > equivalent hacks up the linker scripts -- which seems as "correct" as > one could reasonably hope for... pretty sexy.
by default it doesn't. with the elibtoolize hacks and the drive for .pc files,
this has been largely mitigated. although the latest libtool has a --with-
sysroot option that needs investigating.
> >> If the Makefiles are building against libraries expected to be in
> >> ${PWD}, it seems to me that the Makefiles should know to look there
> >> automatically.
> >
> > yes, so why is the ebuild specifying -L. for it ? the package should
> > already have a -L to the right place, and if it wants to make sure it
> > gets used before the user's LDFLAGS, it should show up in the linking
> > before it (or have the build system prepend the value to LDFLAGS if it's
> > appending currently).
>
> If we decide that manipulating LDFLAGS is correct, whether we do this
> using my "parser" or LDFLAGS="-L. ${LDFLAGS}" isn't particularly important.
it's not particularly important, but on one hand, the LDFLAGS parsing logic
should not be in the tree ever. 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.
i'd still lobby for rejecting of invalid LDFLAGS settings and fixing things at
the "right" place.
> In general, if python breaks, folks can end up in pretty bad shape due
> to chicken-and-egg issues with portage. That's the only reason I've
> spent so much effort trying to think this fairly obscure corner-case
> through.
that's really only a problem in the bootstrap case. if an existing system
can't install python, then it isn't like they're screwed since they already
have a working python installed.
> Meanwhile, I've looked into the patches a bit. In regular Gentoo
> nothing special happens to LDFLAGS, but in prefix, there is special
> handling that suggests some avenues of attack. Before I do anything
> further, I want to figure out if it works right without LDPATH
> manipulation on linux, and, if so, whether I can't generalize whatever
> mechanism allows that to happen.
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.
-mike
signature.asc
Description: This is a digitally signed message part.
