[gentoo-dev] [PATCH/RFC] eclass/flag-o-matic.eclass: prepend-ldpath

[Gregory M. Turner]

----[ "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