binutils-pass2: Reword the paragraph about libtool workaround

Well, I was blaming libtool too much.  If the entire Binutils tree uses
libtool this won't happen.  The problem is Binutils building system is
using libtool-style idiom on non-libtool components.

And this issue is not related to cross compiling, at all.  A native
build can exploit the issue as well (see the updated comment).

Maybe I'll submit a patch to GCC (yes, not a typo, GCC is the upstream
of Binutils building system) to fix the issue when I have the mood...

chapter06/binutils-pass2.xml

@@ -43,11 +43,17 @@
   <sect2 role="installation">
     <title>Installation of Binutils</title>
 
-    <!-- Don't remove this until Binutils upstream updates the libtool
-         copy.  On some host distros the issue doesn't show up.  -->
-    <para>Binutils ships an outdated copy of libtool in the tarball.  It lacks
-    sysroot support, so the produced binaries will be mistakenly linked to
-    libraries from the host distro.  Work around this issue:</para>
+    <!-- Don't remove this until Binutils upstream resolves this issue.
+         We can test by building Binutils on a complete system with
+         zlib (libz.so) installed, passing enable-shared and
+         without-system-zlib.  If the resulted libctf.so still links against
+         libz.so (check with readelf -d) despite we are saying
+         without-system-zlib, then the issue is still unresolved.  -->
+    <para>Binutils relies on an internal libtool copy to link against
+    internal static libraries, but the libiberty and zlib copies shipped
+    in the package do not use libtool.  This inconsistency may cause
+    produced binaries mistakenly linked against libraries from the host
+    distro.  Work around this issue:</para>
 
 <screen><userinput remap="pre">sed '6009s/$add_dir//' -i ltmain.sh</userinput></screen>