[RFC] Update to current automake/autoconf/libtool versions.

[Henry Nelson]

> I don't get it.  Why does being able to link have anything to do with
> being native?  Being able to *run* tests has to do with being native,
> but that's not the point, and autoconf already avoids running tests
> when cross-building.  But being able to link has to do with whether

While I don't understand it, this kind of discussion seems to come the
closest in relevance to problems (inability to link, or executables built
that can't find the necessary runtime libraries) I have experienced on
Solaris2.6 after updating to: autoconf-2.56, gcc3.2.1/binutils2.13.1
(ld version 2.13.1).  Details on gcc:
    Configured with: ../gcc-3.2.1/configure --prefix=/opt/gnu
    --disable-nls --enable-languages=c,c++ --enable-static
    --enable-shared --enable-version-specific-runtime-libs --with-gnu-as
    --with-as=/opt/gnu/bin/as --with-gnu-ld --with-ld=/opt/gnu /bin/ld
    --infodir=/usr/local/info --mandir=/usr/local/man --with-libiconv-prefix
    =/usr/local     Thread model: posix

I'm hoping that someone more knowledgeable will be able to write a bug
report and submit it to the developers of the relevant program.  Unless
something is corrected, gcc in its present state is of little use to people
on Solaris2.x as a native compiler.  Personally, I've gone back to 2.7.2.3
until the 3.2 branch is truly ported to Solaris2.x as a native compiler.

As I've already mentioned in previous posts ("how do you get gcc with gnu
ld to work on solaris2.x?", http://gcc.gnu.org/ml/gcc/2002-12/msg00252.html),
too much manual doctoring of variables like LDFLAGS and LIBS has to be done.

For example, in order to compile libiconv (also libtool), the following
environment variables have to be set before running the configure script:
     setenv LDFLAGS "-L/opt/gnu/lib -lgcc_s -R/opt/gnu/lib"
     setenv LIBS "/opt/gnu/lib/libgcc_s.so.1 -Wl,-rpath -Wl,/opt/gnu/lib"
If gcc/ld doesn't have enough sense to do this on its own, then it has no
business using shared objects at all, IMNSHO.

By far the worst experience I've had is with the mail client mutt.  Even
now I have found no solution after weeks of struggling and asking around:
    With configure options "--with-libiconv-prefix=/usr/local
    --with-slang=/usr/local":
       checking whether this iconv is good enough... no
       configure: error: Try using libiconv instead
    So I try to tell the configure script that I do have libiconv
    by adding environment variables 'LDFLAGS "-L/usr/local/lib -liconv
    -R/usr/local/lib" LIBS "/usr/local/lib/libiconv.so -Wl,-rpath
    -Wl,/usr/local/lib"':
       checking whether byte ordering is bigendian... configure: error:
       can not run test program while cross compiling
    Then unsetenv the above, and try a hint I got off of the Internet
    "LD_PRELOAD /usr/local/lib/libiconv_plug.so":
       ld.so.1: sed: fatal: relocation error: file
       /usr/local/lib/libiconv_plug.so: symbol main: referenced symbol
       not found configure: error: can not find sources in  or ..

I can only keep my fingers crossed so long before I just have to move on.

henry nelson