| 1 |
On Thursday 11 October 2012 05:35:21 Gregory M. Turner wrote: |
| 2 |
> On 10/10/2012 9:14 PM, Mike Frysinger wrote: |
| 3 |
> > On Wednesday 10 October 2012 23:37:26 Gregory M. Turner wrote: |
| 4 |
> >> (1) is worse than (2), but it does have some quasi-legitimate usages. |
| 5 |
> >> For example, prefix bootstrap does this (or used to), as do many of the |
| 6 |
> >> crossdev-wrapper scripts. I've also resorted to such usage, myself, |
| 7 |
> >> when repairing a prefix after I've broken its compiler. These cases |
| 8 |
> >> don't really seem completely "correct" or "incorrect" -- about the best |
| 9 |
> >> I can say for them it is that they are mostly efficacious, but prone to |
| 10 |
> >> problems. |
| 11 |
> > |
| 12 |
> > and no, crossdev doesn't do this. it is properly sysrooted. |
| 13 |
> |
| 14 |
> You are right. I guess I was thinking of this: |
| 15 |
> |
| 16 |
> http://tinderbox.x86.dev.gentoo.org/misc/cmerge, |
| 17 |
> |
| 18 |
> Which does use -L but looks pretty ancient. I see now that crossdev's |
| 19 |
> equivalent hacks up the linker scripts -- which seems as "correct" as |
| 20 |
> one could reasonably hope for... pretty sexy. |
| 21 |
|
| 22 |
by default it doesn't. with the elibtoolize hacks and the drive for .pc files, |
| 23 |
this has been largely mitigated. although the latest libtool has a --with- |
| 24 |
sysroot option that needs investigating. |
| 25 |
|
| 26 |
> >> If the Makefiles are building against libraries expected to be in |
| 27 |
> >> ${PWD}, it seems to me that the Makefiles should know to look there |
| 28 |
> >> automatically. |
| 29 |
> > |
| 30 |
> > yes, so why is the ebuild specifying -L. for it ? the package should |
| 31 |
> > already have a -L to the right place, and if it wants to make sure it |
| 32 |
> > gets used before the user's LDFLAGS, it should show up in the linking |
| 33 |
> > before it (or have the build system prepend the value to LDFLAGS if it's |
| 34 |
> > appending currently). |
| 35 |
> |
| 36 |
> If we decide that manipulating LDFLAGS is correct, whether we do this |
| 37 |
> using my "parser" or LDFLAGS="-L. ${LDFLAGS}" isn't particularly important. |
| 38 |
|
| 39 |
it's not particularly important, but on one hand, the LDFLAGS parsing logic |
| 40 |
should not be in the tree ever. on the other, i can stomach much smaller one- |
| 41 |
off hacks like prepending -L. to LDFLAGS if the maintainers of the python |
| 42 |
ebuild really really want to add it. |
| 43 |
|
| 44 |
i'd still lobby for rejecting of invalid LDFLAGS settings and fixing things at |
| 45 |
the "right" place. |
| 46 |
|
| 47 |
> In general, if python breaks, folks can end up in pretty bad shape due |
| 48 |
> to chicken-and-egg issues with portage. That's the only reason I've |
| 49 |
> spent so much effort trying to think this fairly obscure corner-case |
| 50 |
> through. |
| 51 |
|
| 52 |
that's really only a problem in the bootstrap case. if an existing system |
| 53 |
can't install python, then it isn't like they're screwed since they already |
| 54 |
have a working python installed. |
| 55 |
|
| 56 |
> Meanwhile, I've looked into the patches a bit. In regular Gentoo |
| 57 |
> nothing special happens to LDFLAGS, but in prefix, there is special |
| 58 |
> handling that suggests some avenues of attack. Before I do anything |
| 59 |
> further, I want to figure out if it works right without LDPATH |
| 60 |
> manipulation on linux, and, if so, whether I can't generalize whatever |
| 61 |
> mechanism allows that to happen. |
| 62 |
|
| 63 |
my [limited] understanding of the prefix compiler is that they wrap things with |
| 64 |
a custom shell script to inject -L flags behind the back of the compiler at the |
| 65 |
very last possible minute and point to the right place. |
| 66 |
-mike |
Archives