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 "root@localhost"
| #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.
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
