[Qemu-devel] OS X compile fix

[Qemu-devel] OS X compile fix

[Peter Bartoli]

[-- Attachment #1: Type: text/plain, Size: 676 bytes --]


At the recommendation of Mark Cave-Ayland, I'm sending this patch in to remedy a long-time Mac OS X compile issue.  The offsets are a way off in this diff, but it still works.

-peter

--- block/raw-posix.c.orig      2012-12-03 11:37:05.000000000 -0800
+++ block/raw-posix.c   2012-12-03 18:24:47.000000000 -0800
@@ -914,11 +914,11 @@
                         size = 0;
         }
         if (size == 0)
 #endif
 #if defined(__APPLE__) && defined(__MACH__)
-        size = LONG_LONG_MAX;
+        size = LLONG_MAX;
 #else
         size = lseek(fd, 0LL, SEEK_END);
 #endif
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
         switch(s->type) {

[-- Attachment #2: Type: text/html, Size: 2803 bytes --]

Re: [Qemu-devel] OS X compile fix

[Andreas Färber]

Hi,

Am 18.05.2014 01:14, schrieb Peter Bartoli:
> 
> At the recommendation of Mark Cave-Ayland, I'm sending this patch in to
> remedy a long-time Mac OS X compile issue.

Define "long-time"? 2.0 compiled just fine for me on v10.5.8 with
gcc-4.2. I see a number of deprecation and possibly-used-uninitialized
warnings but no breakage. What OSX version and what compiler are you
using, and what error or warning are you seeing without your patch?

Right now on qemu.git I have a different build issue: In scripts/qapi.py
"except IOError as e" needs to be "except IOError, e". But
block/raw-posix.c still builds fine here.

>  The offsets are a way off in
> this diff, but it still works.

Offsets are not the only issue with this "patch", see
http://wiki.qemu-project.org/Contribute/SubmitAPatch

* HTML format
* No Signed-off-by
* No [PATCH]
* Block maintainers not CC'ed (not so important here)
* Insufficient description of what is being fixed

Regards,
Andreas

> --- block/raw-posix.c.orig      2012-12-03 11:37:05.000000000 -0800
> +++ block/raw-posix.c   2012-12-03 18:24:47.000000000 -0800
> @@ -914,11 +914,11 @@
>                          size = 0;
>          }
>          if (size == 0)
>  #endif
>  #if defined(__APPLE__) && defined(__MACH__)
> -        size = LONG_LONG_MAX;
> +        size = LLONG_MAX;
>  #else
>          size = lseek(fd, 0LL, SEEK_END);
>  #endif
>  #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__)
>          switch(s->type) {

Re: [Qemu-devel] OS X compile fix

[Peter Maydell]

On 18 May 2014 09:50, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 18.05.2014 01:14, schrieb Peter Bartoli:
>> At the recommendation of Mark Cave-Ayland, I'm sending this patch in to
>> remedy a long-time Mac OS X compile issue.
>
> Define "long-time"? 2.0 compiled just fine for me on v10.5.8 with
> gcc-4.2. I see a number of deprecation and possibly-used-uninitialized
> warnings but no breakage. What OSX version and what compiler are you
> using, and what error or warning are you seeing without your patch?

Yeah, this must be only a problem on certain OSX setups -- it's
never been an issue for me on 10.8/x86_64.

That said, it looks like LONG_LONG_MAX is a pre-C99 version
and LLONG_MAX the standard macro name. We use LLONG_MAX
elsewhere (though admittedly only in a test case) so I think it makes
sense to make this change, especially if it fixes compilation on some
setups.

(This use of LONG_LONG_MAX has been in the codebase since
2006, so presumably any configs which somehow fail to provide
this macro have always failed to build without this fix...)

> Right now on qemu.git I have a different build issue: In scripts/qapi.py
> "except IOError as e" needs to be "except IOError, e". But
> block/raw-posix.c still builds fine here.

"except .. as" came in with python 2.6; we need to use the older
syntax since we must work with 2.4 still. (Compare commit
21e0043bada1 where we fixed a previous round of this.)

thanks
-- PMM

Re: [Qemu-devel] OS X compile fix

[Peter Bartoli]

On May 18, 2014, at 4:40 AM, Peter Maydell <peter.maydell@linaro.org> wrote:
> On 18 May 2014 09:50, Andreas Färber <andreas.faerber@web.de> wrote:
>> Am 18.05.2014 01:14, schrieb Peter Bartoli:
>>> At the recommendation of Mark Cave-Ayland, I'm sending this patch in to
>>> remedy a long-time Mac OS X compile issue.
>> 
>> Define "long-time"? 2.0 compiled just fine for me on v10.5.8 with
>> gcc-4.2. I see a number of deprecation and possibly-used-uninitialized
>> warnings but no breakage. What OSX version and what compiler are you
>> using, and what error or warning are you seeing without your patch?
> 
> Yeah, this must be only a problem on certain OSX setups -- it's
> never been an issue for me on 10.8/x86_64.
> 
> That said, it looks like LONG_LONG_MAX is a pre-C99 version
> and LLONG_MAX the standard macro name. We use LLONG_MAX
> elsewhere (though admittedly only in a test case) so I think it makes
> sense to make this change, especially if it fixes compilation on some
> setups.
> 
> (This use of LONG_LONG_MAX has been in the codebase since
> 2006, so presumably any configs which somehow fail to provide
> this macro have always failed to build without this fix...)
> 
>> Right now on qemu.git I have a different build issue: In scripts/qapi.py
>> "except IOError as e" needs to be "except IOError, e". But
>> block/raw-posix.c still builds fine here.
> 
> "except .. as" came in with python 2.6; we need to use the older
> syntax since we must work with 2.4 still. (Compare commit
> 21e0043bada1 where we fixed a previous round of this.)

So, just to add, in case it's helpful, "long time" means since 2012-ish, when QEMU first came to my attention.  I'm almost always running the current version of Mac OS X on the only system I'm running QEMU on, and have always had to use that patch to compile it.  This makes me wonder what I'm missing that gives you that macro.

I'm currently running Mac OS X 10.9.3 (current), I use the following configure options ...

--sysconfdir=/usr/local/share --mandir=/usr/local/man --enable-system --enable-user --enable-cocoa --disable-sdl --disable-gtk --enable-vhost-net --enable-guest-agent --enable-vhdx

... and whether I compile with Apple's built-in compiler, Apple LLVM version 5.1 (clang-503.0.40) ...

  CC    block/raw-posix.o
block/raw-posix.c:1189:16: error: use of undeclared identifier 'LONG_LONG_MAX'
        size = LONG_LONG_MAX;

... or apple-gcc-4.2 from MacPorts, which used to be the only option for me to successfully compile QEMU ...

  CC    block/raw-posix.o
block/raw-posix.c: In function 'raw_getlength':
block/raw-posix.c:1189: error: 'LONG_LONG_MAX' undeclared (first use in this function)
block/raw-posix.c:1189: error: (Each undeclared identifier is reported only once
block/raw-posix.c:1189: error: for each function it appears in.)
make: *** [block/raw-posix.o] Error 1

... or gcc 4.8, also wfrom MacPorts, I still get the same error.

  CC    block/raw-posix.o
block/raw-posix.c: In function 'raw_getlength':
block/raw-posix.c:1189:16: error: 'LONG_LONG_MAX' undeclared (first use in this function)
         size = LONG_LONG_MAX;
                ^
block/raw-posix.c:1189:16: note: each undeclared identifier is reported only once for each function it appears in
block/raw-posix.c: In function 'hdev_open':
block/raw-posix.c:1583:23: warning: variable 'kernResult' set but not used [-Wunused-but-set-variable]
         kern_return_t kernResult;
                       ^
make: *** [block/raw-posix.o] Error 1

-peter

Re: [Qemu-devel] OS X compile fix

[Peter Maydell]

On 18 May 2014 23:45, Peter Bartoli <peter@bartoli.org> wrote:
> So, just to add, in case it's helpful, "long time" means since 2012-ish, when QEMU first came to my attention.  I'm almost always running the current version of Mac OS X on the only system I'm running QEMU on, and have always had to use that patch to compile it.  This makes me wonder what I'm missing that gives you that macro.

For me this simple test program builds:

manooth$ cat /tmp/zz9.c
#include <limits.h>
#include <stdio.h>

int main(void) {
    printf("LONG_LONG_MAX = %llx\n", LONG_LONG_MAX);
    return 0;
}
manooth$ clang -o /tmp/zz9  /tmp/zz9.c
manooth$ /tmp/zz9
LONG_LONG_MAX = 7fffffffffffffff
manooth$ clang --version
Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
Target: x86_64-apple-darwin12.5.0
Thread model: posix

and looking at the preprocessor output it's defined in
/usr/lib/clang/5.0/include/limits.h

(with some include guards, but we're not compiling with
flags that force strict ANSI mode).

However this is just for interest's sake -- we should use the
standard-defined macro rather than the GNU extension
where the former exists...

thanks
-- PMM

Re: [Qemu-devel] OS X compile fix

[Peter Bartoli]

[-- Attachment #1: Type: text/plain, Size: 271 bytes --]


On May 18, 2014, at 4:09 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
> and looking at the preprocessor output it's defined in
> /usr/lib/clang/5.0/include/limits.h

Thanks, Peter ... I don't have a /usr/lib/clang ... where are you getting it from?

-peter

[-- Attachment #2: Type: text/html, Size: 1233 bytes --]

Re: [Qemu-devel] OS X compile fix

[Peter Maydell]

On 19 May 2014 01:06, Peter Bartoli <peter@bartoli.org> wrote:
> On May 18, 2014, at 4:09 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>
> and looking at the preprocessor output it's defined in
> /usr/lib/clang/5.0/include/limits.h
>
>
> Thanks, Peter ... I don't have a /usr/lib/clang ... where are you getting it
> from?

Pretty sure this is just the standard way XCode command line
tools install on 10.8. Googling suggests that 10.9 does things
differently (leaving the headers under /Applications/Xcode.app,
and using shim executables to redirect the paths it looks for). In
that case the header is likely to be
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/5.1/include/limits.h

thanks
-- PMM

Re: [Qemu-devel] OS X compile fix

[Aggeler Fabian]

You’re configuration works for me on 10.9 with clang from the XCode command line tools.

$ xcode-select --install

$ clang --version
Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)
Target: x86_64-apple-darwin13.2.0
Thread model: posix

Best,
Fabian

On 19 May 2014, at 10:19, Peter Maydell <peter.maydell@linaro.org> wrote:

> On 19 May 2014 01:06, Peter Bartoli <peter@bartoli.org> wrote:
>> On May 18, 2014, at 4:09 PM, Peter Maydell <peter.maydell@linaro.org> wrote:
>> 
>> and looking at the preprocessor output it's defined in
>> /usr/lib/clang/5.0/include/limits.h
>> 
>> 
>> Thanks, Peter ... I don't have a /usr/lib/clang ... where are you getting it
>> from?
> 
> Pretty sure this is just the standard way XCode command line
> tools install on 10.8. Googling suggests that 10.9 does things
> differently (leaving the headers under /Applications/Xcode.app,
> and using shim executables to redirect the paths it looks for). In
> that case the header is likely to be
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/clang/5.1/include/limits.h
> 
> thanks
> -- PMM
> 
>