Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] [Wireshark-commits] rev 50204: /trunk/ /trunk/: configure.ac

From: Guy Harris <guy@xxxxxxxxxxxx>
Date: Fri, 28 Jun 2013 10:56:38 -0700
On Jun 28, 2013, at 5:20 AM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:

> On 06/28/13 04:36, guy@xxxxxxxxxxxxx wrote:
>> http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=rev&revision=50204
>> 
>> User: guy
>> Date: 2013/06/28 01:36 AM
>> 
>> Log:
>>  AC_PROG_CXX doesn't actually check whether what it finds is a real live
>>  C++ compiler (it might not be one on, for example, OS X, due to "cc"
>>  being a C compiler, "CC" referring to "cc" due to the case-insensitivity
>>  of the default OS X file system, and "CC" being one of the names checked
>>  for in AC_PROG_CXX), so if we really need a C++ compiler, test it with a
>>  program that a C compiler won't compile.
> 
> Presumably this change can/should be pushed upstream to the autoconf folks?

Or, at least, suggested.  I suspect if you have, on your system, no C compiler, but have a shell script

	#! /bin/sh
	echo "Hello, world!"

named "cc", AC_PROG_CC will cheerfully choose it as your C compiler.

I've filed a bug on it, but I suggested that this might be a somewhat artificial problem; if you have a UN*X with a case-insensitive file system, you're probably on OS X, and you probably have c++/g++, which will be checked before CC.

This came up when I had a glitch when I did

	CC=clang ./configure --with-gtk2 --with-qt

The underlying problem is that

	1) in Xcode 4.6.3, llvm-gcc (including g++) doesn't support -Wvla, but clang (including clang++) does;

	2) that configuration causes clang to be picked as the C compiler and g++ to be picked as the C++ compiler, and causes the C++ compiler to be used;

	3) our "add this option if the compiler supports it" autoconf macro, if not told to add it only to CFLAGS or CXXFLAGS, will check whether the C compiler supports it and, if so, add it both to CFLAGS and CXXFLAGS (i.e., it assumes the C and C++ compilers are siblings).

I forget what I was doing, when debugging that problem, that got me to think we needed to make sure we didn't end up with cc as the C++ compiler.

I'm not sure what we should do about

	CC=clang ./configure --with-gtk2 --with-qt

We could make the "add this option if the compiler supports it" test it separately with the C and C++ compilers, and add it to CFLAGS and/or CXXFLAGS based on the results of both tests; that'd fix the -Wvla problem (and other problems of that sort), and might let us simplify the "add this option if the compiler supports it" code (by having a "add this option to CFLAGS if the C compiler supports it" macro, an "add this option to CXXFLAGS if the C++ compiler supports it", and an "add this option to CFLAGS if the C compiler supports it and CXXFLAGS if the C++ compiler supports it" macro that just runs the previous two; the former two can be used for the C-specific and C++-specific options).

It still doesn't warn you that you've only specified one alternative compiler, and probably really wanted to override the default for both, however.