----[ "eclass/flag-o-matic.eclass" ]----->8----->
--- PORTAGE/eclass/flag-o-matic.eclass
+++ OVERLAY/eclass/flag-o-matic.eclass
@@ -117,6 +117,42 @@
return 0
}
+# @FUNCTION: prepend-ldpath
+# @USAGE: <path>
+# @DESCRIPTION:
+# Place the specified ldpath into LDFLAGS before any options which could
+# add additional paths to ld's search path. Specifically, it will place
+# the new <path> "/foo" into LDFLAGS as "-L/foo" just before the first
+# occurance matching any of the globs: '-L*', '-T', '--library-path*',
+# and '--script*', but not matching any of the globs: '-Tbss=*',
+# '-Tdata=*', '-Ttext=*', and '-Ttext-segment=*'. If no such match is
+# found, then this is equivalent to "append-ldflags -L<path>".
+prepend-ldpath() {
+ local new=()
+ local f
+ local done=no
+ for f in ${LDFLAGS} ; do
+ case "${f}" in
+ -Tbss=*|-Tdata=*|-Ttext=*|-Ttext-segment=*)
+ new+=( "${f}" )
+ ;;
+ -L*|-T*|--library-path*|--script*)
+ if [[ ${done} == yes ]] ; then
+ new+=( "${f}" )
+ else
+ new+=( "-L${1}" "${f}" )
+ done=yes
+ fi
+ ;;
+ *)
+ new+=( "${f}" )
+ ;;
+ esac
+ done
+ [[ ${done} == no ]] && new+=( "-L${1}" )
+ export LDFLAGS="${new[*]}"
+}
+
# @FUNCTION: filter-lfs-flags
# @DESCRIPTION:
# Remove flags that enable Large File Support.
<-----8<-----
I think my code is probably fine, or if it's buggy, so be it. A prior
question is: does this have sufficient utility?
I "need" (not exactly... keep reading) something like this for python.
Currently python*.ebuild contains:
append-ldflags "-L."
which is required in order to pull in the newly-rebuilt
libpython${VERSION}.so at ebuild-time, instead of the system version
(perhaps it's only so on obscure platforms?).
The problem is, LDFLAGS may already have some library paths coming in
from the environment. In this case, we end up with something like:
LDFLAGS="-Wl,--engage-warp-engines -L/random/prefix/usr/lib -L."
and python goes ahead links everything against, i.e.:
/random/prefix/usr/lib/libpython3.2.so,
or whatever is the version in question, so we achieve precisely nothing,
effecting the outcome we are trying to prevent (the problem manifests in
subtle, hard-to-diagnose ways, unfortunately).
In general, when we say append-ldflags -Lsomething, we may or may not
mean "always use something/libfoo, not $(libdir)/libfoo to link." In
the case where we do mean "always", append-ldflags is a broken approach.
An alternative would be to just replace
append-ldflags "-L."
with
export LDFLAGS="-L. ${LDFLAGS}".
however, there are problems with this:
First, it's aesthetically annoying that this spreads out the "-L*"
arguments into two different "zones" in LDFLAGS. No big deal, but it
definitely doesn't make visually scanning the logs any easier.
Second, although I'm not aware of any ld arguments which act as
"modifiers" to "-L" arguments (except the other -L arguments and
ldscript arguments, which the above patch scans for), ld does use
order-dependent patterns for other arguments.
For example: "-lfoo -( -lbar -lbaz -)" is not the same thing as "-(
-lfoo -lbar -) -lbaz". So order-dependencies might emerge in some
future binutils... in that case we'd still probably need to extend the
case statement above to include the new order-affecting arguments, but
at least we'd have a place in which to do so.
Third, although the meaning of -L* options may not be affected by other
arguments in an order-dependant manner, the reverse is not so. For
example, see --mri-script, --script (which both can affect and be
affected by the command-line library search path in an order-dependent
manner!), -rpath-link (SunOS only), etc...
One could certainly argue that, in practice, points two and three amount
to hopelessly obscure nitpicking and that nobody in their right mind
should be relying on this type of stuff in their LDFLAGS.
I'm not sure I'd state it quite so strongly as that, (after all these
might come just from profile.bashrc and be targeted to a particular
ebuild) but justification is clearly on the "thin" side.
Indeed, if we're going to worry about side effects, it's not entirely
clear that what what my patch does is safe. For example, if the
environment supplied "-L/foo/bar --script baz", and python for some
reason had a "baz" file in "${S}", then some kind of breakage would
surely happen when we did
prepend-ldpath "."
Also, we might also legitimately worry that the presence of this
function in flag-o-matic will somehow "encourage" people to do this
more, and, I'd have to agree that it's a pretty shitty approach to
getting gcc to find your generated libraries (perhaps I could answer
this concern by means of some kind of "don't use unless you must"
disclaimer, or by grafting this code into python.eclass during configure()?)
Gross as it may be, it's the approach we've adopted in dev-lang/python*,
a critically important, mandatory package, and it's broken. It's
definitely not just an academic problem, at least not for my
cygwin-overlay where it makes it impossible to toggle USE=threads for
this package. Presumably the same goes for BSD and any other platforms
relying on
So we either need to fix the tactics or the strategy -- personally I'm a
bit reluctant to mess with the latter, which, I guess, is how I end up
with the above, despite some misgivings.
-gmt
