Re: [Qemu-devel] qemu fails to build with glibc-2.15

[X O]

On Tue, Jul 17, 2012 at 11:51 AM, Peter Maydell
<address@hidden> wrote:
> On 17 July 2012 10:38, X O <address@hidden> wrote:
>> On Mon, Jul 16, 2012 at 6:35 PM, X O <address@hidden> wrote:
>>> On Mon, Jul 16, 2012 at 5:14 PM, Avi Kivity <address@hidden> wrote:
>>>> (fixed mailing list)
>>>>
>>>> On 07/16/2012 03:37 PM, X O wrote:
>> [...]
>>>>> Is there a way to compile qemu with glibc-2.15?
>> [...]
>>>>> ~~~
>>>>>   CC    i386-linux-user/syscall.o
>>>>> /tmp/qemu-1.1.1/linux-user/syscall.c: In function 'sys_getdents':
>>>>> /tmp/qemu-1.1.1/linux-user/syscall.c:217:1: error: '__NR_getdents'
>>>>> undeclared (first use in this function)
>>>>> /tmp/qemu-1.1.1/linux-user/syscall.c:217:1: note: each undeclared
>>>>> identifier is reported only once for each function it appears in
>>>>> /tmp/qemu-1.1.1/linux-user/syscall.c: In function '_llseek':
>>>>> /tmp/qemu-1.1.1/linux-user/syscall.c:224:1: error: '__NR_lseek'
>>>>> undeclared (first use in this function)
>>
>> Please, see below. I know it is nowhere near clean solution, but it is
>> a quick hack which works for me and might be useful for somebody else.
>> Feel free to kick me in the right direction for a proper patch.
>>
>> I know, some #ifdefs would have to take a place; "<asm/unistd_32.h>"
>> won't be available for all platforms and all glibc versions(?) etc.
>> etc. At least these are the issues I can think off from top of my
>> head.
>>
>> ~~~[CUT]~~~
>> --- linux-user/syscall.c.orig   2012-07-17 09:45:07.000000000 +0200
>> +++ linux-user/syscall.c        2012-07-17 10:36:12.000000000 +0200
>> @@ -25,6 +25,7 @@
>>  #include <endian.h>
>>  #include <errno.h>
>>  #include <unistd.h>
>> +#include <asm/unistd_32.h>
>
> This is (obviously) the wrong thing -- we shouldn't need to
> include asm/ headers and certainly including 32 bit only
> headers will break 64 bit compiles.
>

This is 64bit build.

> My Ubuntu Precise system has (e)glibc-2.15 and it works fine, because:

eglibc ???

>
> * qemu linux-user/syscall.c #includes <linux/unistd.h>
> * /usr/include/linux/unistd.h #includes <asm/unistd.h>

No, it doesn't. It includes <bits/unistd.h> and it "ends" there. It
doesn't work as "expected" anymore(?), resp. beyond glibc-2.15.

> * /usr/include/asm/unistd.h #includes either asm/unistd_32.h
>   or asm/unistd_64.h as appropriate for 32/64 bit compiles.
>
> Is part of this chain broken on your system?
>

Yes, it is "broken" as explained above.

-- bexoff

> -- PMM