On 10/9/2012 2:26 PM, Mike Frysinger wrote:
On Saturday 06 October 2012 03:47:57 Gregory M. Turner wrote:
My god, I am a horrible self-editor. Sorry. Please ignore the magnum
opus above and allow me to try again.
In dev-lang/python*, we use
append-ldflags '-L.'
to ensure linking is performed against the built libpython.so in-tree,
rather than than in the one in $(libdir). But, this doesn't work if
LDFLAGS contains "-L$(libdir)".
well, some notes here ...
for users: putting -L<some-system-path> is wrong. it changes the meaning of
"system paths" when it comes to searching for linking by elevating it to "user
specified path". imo, you should be fixing the source rather than the symptom.
for packagers: using -L$(libdir) is almost always wrong and pointless. the
toolchain itself knows the proper system path to search for libraries to link
against, and when you cross-compile, the --libdir you specify to configure is
not going to be valid when dereferenced on the build system.
Agreed on these points. Not until we combine the doubly broken
circumstances of (1) User specified -L/usr/$(libdir) in LDPATH and (2)
an ebuild that puts -L. into LDPATH to fix Makefile recipes that appear
more-or-less broken, do we get this conflict. This leads to a certain
odor of "unsupportable circumstances" which, I must admit, makes me
slightly uncomfortable trying to fix it.
Breaking this down:
(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.
As for (2)... meh. LDFLAGS, to my thinking, means something like: "Use
these guidelines and parameters for linking, in preference to the
default guidelines that the build process would normally use." LDFLAGS
coming from make.conf have a slightly different meaning, I guess, but
the gist of it is the same.
So technically speaking, LDFLAGS="-L. ${LDFLAGS}" or similar is not a
complete abomination. Still... I don't like it.
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.
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.
-gmt
