[REBASED PATCH 0/9] Paolo's sysroot patches, rebased plus some fixes

[Charles Wilson]

These are rebased versions of Paolo's sysroot patches, rebased to
0e01d00c70fe1eba2b746a6bb52e3c9277a4f1ef (Sun Jul 18 17:17:15 2010 +0200)

As it happens, Paolo's old 3/8 'provide shell functions to configure.patch' 
didn't
apply very well at all, given the recent changes.  So, I took the brute force
approach with 9/9 in this series: 'Configure script should not use libtool-only
shell functions'

Also, recent autoconf broke one of the constructs used in Paolo's sysroot
test (Paolo's old 5/8, 4/9 in this series).  This is fixed by 5/9 in this
series.

Charles Wilson (2):
  (5/9) Fix issue with GROW diversion in testsuite
  (9/9) Configure script should not use libtool-only shell functions

Paolo Bonzini (7):
  (1/9) handle sysroot flags       [was 1/8]
  (2/9) fix buglet                 [was 2/8]
  (3/9) Add --with-sysroot         [was 4/8]
  (4/9) add a basic sysroot test   [was 5/8]
  (6/9) teach libtool -L= and -R=  [was 6/8]
  (7/9) handle sysrooted paths when reading dependencies to la files [was 7/8]
  (8/9) emit sysrooted paths when installing .la files               [was 8/8]

Test results:
sysroot.at tested on native cygwin (all skipped) and cygwin->mingw cross
(all pass).  Full test suite run on native cygwin.  There were some regressions,
which appear to be due to this patch series, and I'll investigate that later.

The end result is that the .la file when a library is built cross contains
stuff like this:
# Libraries that this one depends upon.
dependency_libs=' =/mingw/lib/lib1.la =/mingw/lib/lib1.la'
...
# Directory that this library needs to be installed in:
libdir='/mingw/lib'

(where the library itself was configured with --prefix=/mingw while the
cross-compiler's sysroot is /usr/i686-pc-mingw32/sys-root (e.g. you do
not configure with --prefix=$sysroot$real_prefix).

The new libtool knows how to interpret the '=' when using a sys-root (e.g.
a cross compiler).  I haven't yet tested how a NATIVE compiler/libtool
reacts when you try to link against an .la file that was created elsewhere
using a cross compiler/libtool combo. First things first:


The regressions mostly appear to involve C++ tests and shared libraries:
Old:
tagdemo-make after tagdemo-conf, tagdemo-shared, or tagdemo-undef

New:
 41: Runpath in libtool library files       FAILED (runpath-in-lalib.at:61)
101: C++ exception handling                 FAILED (exceptions.at:371)
111: Run tests with low max_cmd_len         FAILED (cmdline_wrap.at:43)
112: override pic_flag at configure time    FAILED (pic_flag.at:48)

Now, 112 is a false alarm; it should be skipped on non-ELF and is not a
regression. 111 is a result of the other failures.  That leaves 101 and
41.  101 is due to the C++ problem, but 41 appears to be because the
new sysroot replacement code is overzealous, but I need to investigate
more.

The C++ problem is basically that the postdeps don't get populated properly.
I'm not yet sure why, but here's the relevant portion of the CXX tag from
a "good" libtool:

======================== good =============================
# The directories searched by this compiler when creating a shared library.
compiler_lib_search_dirs="/usr/lib/gcc/i686-pc-cygwin/4.3.4 
/usr/lib/gcc/i686-pc-cygwin/4.3.4 
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib 
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.."

# Dependencies to place before and after the objects being linked to
# create a shared library.
predep_objects="/usr/lib/gcc/i686-pc-cygwin/4.3.4/crtbegin.o"
postdep_objects="/usr/lib/gcc/i686-pc-cygwin/4.3.4/crtend.o"
predeps=""
postdeps="-lstdc++ -lgcc_s -lgcc_s -lcygwin -luser32 -lkernel32 -ladvapi32 
-lshell32 -lgcc_s -lgcc_s"

# The library search path used internally by the compiler when linking
# a shared library.
compiler_lib_search_path="-L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.."

# ### END LIBTOOL TAG CONFIG: CXX
===========================================================

And here's the "bad" libtool:
========================= bad =============================
# The directories searched by this compiler when creating a shared library.
compiler_lib_search_dirs="/usr/lib/gcc/i686-pc-cygwin/4.3.4 
/usr/lib/gcc/i686-pc-cygwin/4.3.4 
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib 
/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. conftest.o"

# Dependencies to place before and after the objects being linked to
# create a shared library.
predep_objects="/usr/lib/gcc/i686-pc-cygwin/4.3.4/crtbegin.o"
postdep_objects=""
predeps=""
postdeps=""

# The library search path used internally by the compiler when linking
# a shared library.
compiler_lib_search_path="-L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../../../i686-pc-cygwin/lib 
-L/usr/lib/gcc/i686-pc-cygwin/4.3.4/../../.. -Lconftest.o"

# ### END LIBTOOL TAG CONFIG: CXX
===========================================================

I'm not exactly sure how any of these changes cause THAT to occur, but I'll keep
looking in to it.  However, hopefully these rebased patches will let others join
in!

As an aside, WHY is it that libtool tries to figure out what the language driver
does, and use ld directly, rather than just trust the language driver and use it
to link instead?  It seems that the current libtool behavior causes a lot of
problems because it is quite fragile...

 Makefile.am                |    3 +-
 libltdl/config/ltmain.m4sh |  150 +++++++++++++++++++++++++--------
 libltdl/m4/libtool.m4      |   92 +++++++++++++++++++-
 tests/sysroot.at           |  201 ++++++++++++++++++++++++++++++++++++++++++++
 4 files changed, 405 insertions(+), 41 deletions(-)
 create mode 100644 tests/sysroot.at

--
Chuck