Hello Jason, * 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? 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. 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 The build then fails due to the ugliness that is ltdl.c ;-) and issues listed below, but otherwise looks like it should more or less work for other packages. False test result are experienced with AC_CHECK_LIB, AC_SEARCH_LIBS, even if you have previously installed (or compiled) lint libraries somewhere and pointed to them with LDFLAGS=-L/path/to/lint/libs. (This lint has means to create files that describe APIs for object files and libraries, which it calls 'lint libraries'; such pre-generated libraries are available for libc and many others.) However, the syntax this lint uses (`-o' for naming the lint library to be created, and also turning off undefined functions warnings) is incompatible with Autoconf tests that use `-o conftest' and later check for this program. Similar issues exist of course for AC_CHECK_FUNC*. The default compiler output name is detected wrongly as b.out (but that is mostly inconsequential as we're talking configure into a cross-compile situation anyway). I did not see other obvious false test results. It would help to get exposure by trying more packages (and yes, I have not yet tried to compare Autoconf's test suite's output with this). 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). (Unrelated side note FYI: if you pass CC as argument rather than in the environment, then config.status will remember it when it triggers a recheck.) > Anybody know of a project that has Solaris' lint incorporated that I can > use as an example? I'm guessing it needs changes to the Makefile.am files I > have to add new targets. Actually, I would hope that we could patch Autoconf (and maybe some third-party macros) a little so that it would not need any changes to your projects. > Right now to capture any mistakes I make I run GCC > and Solaris' CC. GCC doesn't capture some of the errors, especially type > related ones. FWIW, other lint-style checkers that I've found helpful before: <http://www.splint.org/> (development has stalled a bit here), <http://www.kernel.org/pub/software/devel/sparse/>. > 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. Cheers, Ralf _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
