[2/2] Support using a different compiler for Objective-C files

MacOSX 10.8 ("Mountain Lion") requires us to compile our one
Objective-C source file with clang even if the rest of QEMU
requires a real gcc, because the system headers we use make
use of Apple's "Blocks" extension to C/ObjC, and mainline
gcc doesn't support that. Since we only need to use a true
gcc for the parts of QEMU that use the fixed-register
env variable, we can simply use clang to build the ObjC
file: it will link to the gcc-built objects with no problems.

Add the necessary support for an OBJCC variable in the
makefile and configure machinery; we default to clang
if we have it, otherwise whatever CC is (since gcc
might be the Apple gcc which does support Blocks).

Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
---
 configure | 12 ++++++++++++
 rules.mak |  2 +-
 2 files changed, 13 insertions(+), 1 deletion(-)

Am 11.08.2012 23:34, schrieb Peter Maydell:
> MacOSX 10.8 ("Mountain Lion") requires us to compile our one
> Objective-C source file with clang even if the rest of QEMU
> requires a real gcc, because the system headers we use make
> use of Apple's "Blocks" extension to C/ObjC, and mainline
> gcc doesn't support that. Since we only need to use a true
> gcc for the parts of QEMU that use the fixed-register
> env variable, we can simply use clang to build the ObjC
> file: it will link to the gcc-built objects with no problems.
> 
> Add the necessary support for an OBJCC variable in the
> makefile and configure machinery; we default to clang
> if we have it, otherwise whatever CC is (since gcc
> might be the Apple gcc which does support Blocks).
> 
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
>  configure | 12 ++++++++++++
>  rules.mak |  2 +-
>  2 files changed, 13 insertions(+), 1 deletion(-)
> 
> diff --git a/configure b/configure
> index be4a2bb..bd62d2c 100755
> --- a/configure
> +++ b/configure
> @@ -534,6 +534,13 @@ fi
>  : ${python=${PYTHON-python}}
>  : ${smbd=${SMBD-/usr/sbin/smbd}}
>  
> +# Default objcc to clang if available, otherwise use CC
> +if has clang; then
> +  objcc=clang

On IRC I had commented that I find defaulting to clang whenever clang is
available too aggressive (it may be some /usr/local/bin version that
doesn't even have the right host architecture support compiled in).
I won't object to this patch but would appreciate a follow-up limiting
this to v10.8+ where it's actually needed and keep using gcc elsewhere.

Andreas

> +else
> +  objcc="$cc"
> +fi
> +
>  if test "$mingw32" = "yes" ; then
>    EXESUF=".exe"
>    QEMU_CFLAGS="-DWIN32_LEAN_AND_MEAN -DWINVER=0x501 $QEMU_CFLAGS"
> @@ -577,6 +584,8 @@ for opt do
>    ;;
>    --host-cc=*) host_cc="$optarg"
>    ;;
> +  --objcc=*) objcc="$optarg"
> +  ;;
>    --make=*) make="$optarg"
>    ;;
>    --install=*) install="$optarg"
> @@ -1024,6 +1033,7 @@ echo "  --cross-prefix=PREFIX    use PREFIX for compile tools [$cross_prefix]"
>  echo "  --cc=CC                  use C compiler CC [$cc]"
>  echo "  --host-cc=CC             use C compiler CC [$host_cc] for code run at"
>  echo "                           build time"
> +echo "  --objcc=OBJCC            use Objective-C compiler OBJCC [$objcc]"
>  echo "  --extra-cflags=CFLAGS    append extra C compiler flags QEMU_CFLAGS"
>  echo "  --extra-ldflags=LDFLAGS  append extra linker flags LDFLAGS"
>  echo "  --make=MAKE              use specified make [$make]"
> @@ -3054,6 +3064,7 @@ fi
>  echo "Source path       $source_path"
>  echo "C compiler        $cc"
>  echo "Host C compiler   $host_cc"
> +echo "Objective-C compiler $objcc"
>  echo "CFLAGS            $CFLAGS"
>  echo "QEMU_CFLAGS       $QEMU_CFLAGS"
>  echo "LDFLAGS           $LDFLAGS"
> @@ -3521,6 +3532,7 @@ echo "PYTHON=$python" >> $config_host_mak
>  echo "CC=$cc" >> $config_host_mak
>  echo "CC_I386=$cc_i386" >> $config_host_mak
>  echo "HOST_CC=$host_cc" >> $config_host_mak
> +echo "OBJCC=$objcc" >> $config_host_mak
>  echo "AR=$ar" >> $config_host_mak
>  echo "OBJCOPY=$objcopy" >> $config_host_mak
>  echo "LD=$ld" >> $config_host_mak
> diff --git a/rules.mak b/rules.mak
> index a284946..1b173aa 100644
> --- a/rules.mak
> +++ b/rules.mak
> @@ -29,7 +29,7 @@ endif
>  	$(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  AS    $(TARGET_DIR)$@")
>  
>  %.o: %.m
> -	$(call quiet-command,$(CC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  OBJC  $(TARGET_DIR)$@")
> +	$(call quiet-command,$(OBJCC) $(QEMU_INCLUDES) $(QEMU_CFLAGS) $(QEMU_DGFLAGS) $(CFLAGS) -c -o $@ $<,"  OBJC  $(TARGET_DIR)$@")
>  
>  LINK = $(call quiet-command,$(CC) $(QEMU_CFLAGS) $(CFLAGS) $(LDFLAGS) -o $@ $(sort $(1)) $(LIBS),"  LINK  $(TARGET_DIR)$@")
>  
>

On 15 August 2012 15:47, Andreas Färber <afaerber@suse.de> wrote:
> Am 11.08.2012 23:34, schrieb Peter Maydell:
>> +# Default objcc to clang if available, otherwise use CC
>> +if has clang; then
>> +  objcc=clang
>
> On IRC I had commented that I find defaulting to clang whenever clang is
> available too aggressive (it may be some /usr/local/bin version that
> doesn't even have the right host architecture support compiled in).
> I won't object to this patch but would appreciate a follow-up limiting
> this to v10.8+ where it's actually needed and keep using gcc elsewhere.

Mmm. It might be better to explicitly test for a compiler
with Blocks support (although even then you might end up
with clang on pre-10.8; I don't really want to check for "does
header Foo need blocks support" because that seems a bit fragile.)

-- PMM

Am 15.08.2012 16:55, schrieb Peter Maydell:
> On 15 August 2012 15:47, Andreas Färber <afaerber@suse.de> wrote:
>> Am 11.08.2012 23:34, schrieb Peter Maydell:
>>> +# Default objcc to clang if available, otherwise use CC
>>> +if has clang; then
>>> +  objcc=clang
>>
>> On IRC I had commented that I find defaulting to clang whenever clang is
>> available too aggressive (it may be some /usr/local/bin version that
>> doesn't even have the right host architecture support compiled in).
>> I won't object to this patch but would appreciate a follow-up limiting
>> this to v10.8+ where it's actually needed and keep using gcc elsewhere.
> 
> Mmm. It might be better to explicitly test for a compiler
> with Blocks support (although even then you might end up
> with clang on pre-10.8; I don't really want to check for "does
> header Foo need blocks support" because that seems a bit fragile.)

A simple does-clang-compile-a-hello-word-for-host check, falling back to
gcc, should catch the worst regressions as well.

Andreas