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.
further, you cannot do multilib with users putting -L<system libdir> into
their LDFLAGS. they just forced a single ABI and any other will simply fail.
the toolchain's compiler driver knows exactly where to find its own libraries.
if it doesn't, it's broken, and it should be fixed.
ACK
So technically speaking, LDFLAGS="-L. ${LDFLAGS}" or similar is not a
complete abomination. Still... I don't like it.
it's significantly better than the proposed code which tries to parse the
meaning of various flags and insert it at the "right" point. i can't see it
being useful at all. it's a recipe for fragility and being unmaintainable.
I think I meant the above differently than you interpreted it: I meant
that solving library-search-path selection in autotools steps and/or
Makefile.in would make the question of how to manipulate LDFLAGS
academic, and seems more elegant. Apparently you agree:
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.
My point above was that coming to that decision in the first place
suggests some underlying issue exists that arguably ought to be fixed
instead.
i'm not sure why this applies to the larger build system. i can understand
that the python build itself might not be putting the -L. in a place where a
user's misconfigured LDFLAGS will cause a problem.
This only pertains to dev-lang/python AFAIK... there may be others
lurking out there somewhere, but I'm not too worried about them. The
use-cases I have in mind are prefix bootstrap and system-recovery when
gcc breaks.
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.
-gmt
P.S.: After poking around, the first commit where this appeared is this
one:
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-lang/python/python-2.5.1.ebuild?hideattic=0&r1=1.4&r2=1.5&view=patch,
a mere 5.5 years ago by uberlord.
The cvs ChangeLog references bug 177426 which doesn't seem particularly
illuminating. It also says:
export LDFLAGS=-L. so we link modules correctly on FreeBSD
and possibly other systems where python2.5 isn't installed yet.
Which at least seems to confirm that this was originally a problem not
of search path ordering, but of complete failure to search ${S} in the
first place.
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.
