Re: compensate compiler warnings and boilerplate

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Mon, Apr 11, 2005 at 10:33:25AM CEST:
> Ralf Wildenhues wrote:
> > Two problems I want to kill with this patch:
> > - picky compiler(s|flags) warn about innocuous code and thus make the
> >   `-c -o' and the pic_flag tests (among others) spuriously fail.
> > - some proprietary compilers output boilerplate every time.  Same
> >   effect on libtool tests.
> 
> Excellent idea!

Thanks.

> > I'm unsure whether I should additionally put something like
> >     m4_require(_LT_COMPILER_BOILERPLATE)
> > at the beginning of respective tests?
> 
> By inspection (ie. I haven't actually tested the stuff I'm talking about 
> below):
> 
> I think exposes an inconsistency in the way we handle lt_simple_*_test_code.
> Since their contents are compiler dependent, we should be declaring:
> 
> _LT_TAGVAR(lt_simple_*_test_code, $1)="foo;\n"
> 
> Which implies:
> 
> # _LT_*_BOILERPLATE([TAG])
> # ------------------------
> m4_defun([_LT_*_BOILERPLATE],
> ac_outfile=conftest.$ac_objext
> printf "_LT_TAGVAR(lt_simple_*_test_code, $1)" >conftest.$ac_ext
> eval "$ac_compile" 2>&1 >/dev/null | $SED '/^$/d' >conftest.err
> _LT_TAGVAR(_lt_*_boilerplate, $1)=`cat conftest.err`
> $RM conftest*
> ])# _LT_*_BOILERPLATE
> 
> And that in turn implies the m4_require can't be used, although the calls to
> the BOILERPLATE macros from _LT_LANG_*_CONFIG will need to set the TAG 
> correctly.
> 
> (Yes, I know there are plenty of other misused overloaded shell variables that
> don't yet use the _LT_TAG machinery, but no sense in making things any worse).

This is what I feared.  However, it means I need to make more changes.
Also, doesn't that mean that lt_simple_*_test_code will end up in
`libtool' and being substituted?  I would like a _LT_TAGVAR for
variables to be used in `configure' only[1].  .. time passes..
Ah, you mean using _LT_TAGVAR without also using _LT_TAGDECL, right?

Anyway, the changes you want me to make make more other changes
necessary.  Will look into how ugly the result will end up.

> >     * m4/libtool.m4 (_LT_COMPILER_BOILERPLATE, _LT_LINKER_BOILERPLATE):
> >     New macros: save warnings and boilerplate of simple compile/link tests.
> >         (_LT_LANG_C_CONFIG, _LT_LANG_CXX_CONFIG, _LT_LANG_F77_CONFIG,
> >         _LT_LANG_GCJ_CONFIG, _LT_LANG_RC_CONFIG): Call. 
> >         (_LT_COMPILER_OPTION, _LT_LINKER_OPTION, _LT_COMPILER_C_O, ):
> >         Fail only if nonempty warnings different from default compile/link.
> 
> Fine for HEAD with the _LT_TAG changes.  How serious is the bug it fixes?

Makes at least the following configurations work (better):
  CC=gcc                # CFLAGS containing some deprecated flag
  solaris F77=/opt/SUNWspro/bin/f77 FFLAGS=-xarch-v9
  linux CC=icc CFLAGS=-Wall
  linux CC=icc          # some old version of Intel
  linux CC=pgcc         # with evaluation license still valid for more than 
                        # a couple more days
  linux CC=como         # Comeau compilers
  ...

The first mentioned configuration prompted a bugreport against 1.5.x
recently.  Comeau support is not in Libtool yet, but patches are
currently tested.  Their current compiler version has no switch to turn
off the status message.

> If you think we will save ourselves considerable pain vs bug reports
> against the eventual 2.0 release, I'll leave it to your discretion to
> backport to branch-2-0.  I wouldn't waste anymore time on branch-1-5
> if at all possible though.

Hmm.  Given the number of configurations (esp. the first item has bitten
and is quite surprising if all you do is a gcc upgrade) I might do all
three branches.  For branch-1-5, no abstractions, however.

Regards,
Ralf

[1] so that config.status load does not increase unnecessarily, plus we
don't expose more interface than necessary.  Please note we cannot
sensibly remove variables from `libtool --config' once we have put them
in a release; as long as 2.0 is not out yet..