Re: Autoconf and Solaris Lint

[Jason Curl]

Ralf Wildenhues wrote:
> * Jason Curl wrote on Wed, Jun 20, 2007 at 11:55:54PM CEST:
> > I've searched in vain on the Web how I might run configure to use Solaris' 
> > 'lint' program. It appears that their 'lint' is very much like a compiler 
> > where it produces objects that can be linked together to form a final 
> > result.
> >
> > The command below doesn't work.
> > CC=lint ./configure --host=sparc-sun-solaris2.10
>
> I'd be interested to see which tests come out wrong with the above.
> Could you take a look at config.log and search for obviously wrong
> results?

I've also tried something similar to what you did
  ./configure CC=lint LD=/usr/ccs/bin/ld cross_compile=yes

and the results are:
  checking for C compiler default output file name...
  configure: error: C compiler cannot create executables
  See `config.log' for more details.

Looking at config.log I see:
  configure:2756: lint --version >&5
  lint: unknown option: -
  usage: lint [ options] files.  Use 'lint -flags' for details
  configure:2759: $? = 1
  configure:2766: lint -v >&5
  usage: lint [ options] files.  Use 'lint -flags' for details
  configure:2769: $? = 1
  configure:2776: lint -V >&5
  lint: Sun C 5.8 2005/10/13
  usage: lint [ options] files.  Use 'lint -flags' for details
  configure:2779: $? = 1
  configure:2802: checking for C compiler default output file name
  configure:2829: lint    conftest.c  >&5
  configure:2832: $? = 0
  configure:2870: result:
  configure: failed program was:
  | /* confdefs.h.  */
  | #define PACKAGE_NAME "My Program"
  | #define PACKAGE_TARNAME "MyProg"
  | #define PACKAGE_VERSION "0.4.2.2"
  | #define PACKAGE_STRING "My Program 0.4.2.2"
  | #define PACKAGE_BUGREPORT "address@hidden"
  | #define PACKAGE "MYPROG"
  | #define VERSION "0.4.2.2"
  | #define _GNU_SOURCE 1
  | /* end confdefs.h.  */
  |
  | int
  | main ()
  | {
  |
  |   ;
  |   return 0;
  | }
  configure:2877: error: C compiler cannot create executables
  See `config.log' for more details.

So does it appear autoconf relies on the "compiler" invoking LD 
automatically?

> Next, it would help to see how this fares:
>   ./configure
>   env CC=lint make -e
>
> but of course this is a bit more cumbersome to use.

To start, it depends a lot on the compile configure found when it 
started. There's a lot of options that are GNU specific that 'lint' 
doesn't understand. I've tried it twice, with GCC in the path, and without.

with:
  ganymede:jcurl:LX2005-0.4.2.2$ CC=lint gmake -e
  ...
  lint -DHAVE_CONFIG_H -I.    -DSYSCONFDIR=\"/usr/local/etc\" -O2 -Wall
  -MT console.o -MD -MP -MF .deps/console.Tpo -c -o console.o console.c
  lint: unknown option: M
  lint: unknown option: T
  lint: unknown option: M
  lint: unknown option: M
  lint: file with unknown suffix ignored: console.o
  lint: file with unknown suffix ignored: .deps/console.Tpo
  error: -D option argument not an identifier
  lint: errors in console.c; no output created

without:
  ganymede:jcurl:LX2005-0.4.2.2$ CC=lint dmake -e
  source='console.c' object='console.o' libtool=no \
  DEPDIR=.deps depmode=none /bin/bash ../../config/depcomp \
  lint -DHAVE_CONFIG_H -I.     -DSYSCONFDIR=\"/usr/local/etc\" -g -c
  console.c
  ...
  /usr/ccs/bin/ar cru liblogger.a console.o file.o  output.o profile.o
  queue.o  serial.o strfunc.o tcpip.o  ipcproto.o dbgmsg.o
  appframework.o  confopts.o timersub.o timeradd.o getline.o strnlen.o
  ar: cannot open console.o
        No such file or directory


It gets further, but because I'm building a static library (that I will 
later 'libtoolise') it fails at the part it wants to link with 'ar'. I 
can override that with

  ganymede:jcurl:LX2005-0.4.2.2$ CC=lint AR=lint ARFLAGS='' dmake -e
  ...
  lint  liblogger.a console.o file.o  output.o profile.o queue.o
  serial.o strfunc.o tcpip.o  ipcproto.o dbgmsg.o appframework.o
  confopts.o timersub.o timeradd.o getline.o strnlen.o
  lint: file with unknown suffix ignored: liblogger.a
  lint: file with unknown suffix ignored: console.o
  ...

Reading the manual page for 'lint' it has the following extensions:

     Arguments whose names end with .c are taken to be  C  source
     files;  arguments  ending in .i are taken to be preprocessor
     output files (produced with the -P option to the compiler).

     Arguments whose names end with  .ln  are  taken  to  be  the
     result  of an earlier invocation of lint with either the -C,
     -c, or the -o option used. The .ln files are analogous to .o
     (object)  files  that are produced by the cc(1) command when
     given a .c file as input.  Files  with  other  suffixes  are
     warned about and ignored.

When compiling libraries, we'd probably want to do something a little 
different (again from the manpage):

     lint takes all the .c, .i, .ln, and llib-lx.ln (specified by
     -lx)  files  and processes them in their command-line order.
     By default, lint appends the standard C lint library  (llib-
     lc.ln)  to  the end of the list of files.  When the -C or -c
     option is  used,  the  .ln  and  the  llib-lx.ln  files  are
     ignored.   When  the -C or -c option is not used, the second
     pass of lint checks the .ln and the llib-lx.ln list of files
     for mutual compatibility.

Thus Sun's lint can check linking errors also. Hmm, it might affect 
Automake pretty heavily though as it appears that the extension '.a' is 
pretty much assumed (we'd want to change that to .ln)

> FWIW, I have access to a Solaris 2.8 host that has a lint installed,
> and, just as an example package, I got CVS HEAD Libtool configured with
> something like
>   .../configure CC=lint LD=/usr/ccs/bin/ld cross_compile=yes
>
> All of these failures may be worked around by pre-seeding configure
> in a config.site file with the correct values for the system in
> question (say, taken from a config.cache file generated by a configure
> run that uses CC=cc).

I'm doing this already and certainly would be my preferred solution, 
just didn't know where to start. You're ideas have helped get a bit further.

> > As I'm pretty new to extending Automake/Autoconf, if somebody could hint me 
> > to a framework that would be most helpful.
>
> I hope this helps a bit.

Certainly has.

What would be a nice feature of autoconf would be to recognise lint 
checkers, like how it checks for compilers, with initial support for 
splint, sparse (I've never used that before) and SunStudio 11 (lint) for 
Solaris Sparc.

May be a macro "AC_PROG_LINT" that can check if the cross compiler is 
really lint, figure out the system it's on and based on the lint found 
set some default flags. The 'AC_PROG_CC' will have to be modified, and 
maybe 'AC_PROG_LINT' needs to go before?

As you've probably already guessed, I can do some basics with autoconf, 
make some corrections, but building a basis is something that I'm not 
really capable of doing with my knowledge.

Cheers,
Jason.