[BuildTools] Testing AC_COIN_CREATE_LIBTOOL (Solaris/GCC)

[Lou Hafer]

Andreas,

	Turns out we're not quite done.  Had no problems with Solaris/Studio,
but when I tried Solaris/GCC, ran across another interesting quirk.  Turns out
that not all C/C++ preprocessors return non-zero when they can't find an include
file, and GCC 4.1.1 on Solaris is one of them.  Autotools anticipates this, but
getting it right while skipping AC_PROG_LIBTOOL requires we pass two more
variables, ac_c_preproc_warn_flag and ac_cxx_preproc_warn_flag, to the secondary
configure scripts. The necessary changes are:

  * In COIN_INIT_AUTO_TOOLS, the case label that pulls variables from
    config.status should change to

    s, at am__fastdep* | s, at AR@* | s, at CPP@*  | s, at CPPFLAGS@* | s, at CXXCPP@*  | \
    s, at RANLIB@* | s, at STRIP@* | s, at ac_ct_AR@* | s, at ac_ct_RANLIB@* | \
    s, at ac_ct_STRIP@* | s, at host* | s, at LN_S@* | s, at RPATH_FLAGS@* | \
    s, at ac_c_preproc_warn_flag@* | s, at ac_cxx_preproc_warn_flag@* )

    The last line is the two additional variables.


  * In COIN_PROG_LIBTOOL, after the call of AC_PROG_LIBTOOL, add the lines

     AC_SUBST(ac_c_preproc_warn_flag)
     AC_SUBST(ac_cxx_preproc_warn_flag)

    This gets the two variables into the output variables in config.status.

There doesn't seem to be a corresponding variable for Fortran.

With this tweak, the new coin.m4 with libtool reuse tests out for Solaris/GCC,
Solaris/Studio, and SuSE/GCC. Again, tested with DyLP as project.

	There's one issue for Solaris that we may still need to address.  On my
local installation, there are three `cc' programs.  One is Studio C, one is an
alias for gcc, and the final one is the ancient /usr/ucb/cc (in my case, a shell
wrapper pointing to ucbcc).  Depending on your PATH, you can stumble on this one
when the Studio cc is absent.  Specifying CC=gcc on the configure command line
is the easy fix.  A macro to make the correct decision is problematic.  The
status values returned by the various compilers when you try to extract version
information are not what I'd expect, and not particularly helpful.  Parsing
output has its own risks. Absence of CC (the Studio C++ compiler) might be the
most reliable test. Maybe just a note in the (in)frequently asked questions 
section of Known Issues  :-).

							Lou