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.
they're broken. and no, crossdev doesn't do this. it is properly sysrooted.
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.
> 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.
> 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).
> In the particular case of Gentoo's cpython, I have to admit I'm
> concerned that if I start mucking around with the Makefiles/autotool
> scaffolding, I'm going to break stuff. But maybe it's worth taking that
> risk if it allows us to do things more correctly going forward... I
> could at least take a crack at it and see what people think of the results.
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.
but if you want the right answer, it's to reject broken user LDFLAGS. we
don't support wrong things like -fPIC or -fPIE in global CFLAGS. i don't
think we should be wasting time on LDFLAGS like this either.
-mike
signature.asc
Description: This is a digitally signed message part.
