[Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Sandra Loosemore]

Yesterday I tried to build the recent 4.1 release system-mode QEMU for 
aarch64-none-elf and ran into a compilation error in 
./contrib/libvhost-user/libvhost-user.c.  It's complaining about 
MADV_NOHUGEPAGE not being defined.  I'm not familiar with that code or 
even what it does; should that bit of logic be made conditional on 
MADV_NOHUGEPAGE being defined, or is this indicative of a configuration 
error for this target?  I see the unguarded reference was also present 
in the 3.0 release so it seems like whatever changed is somewhere else, 
and I don't know where to look for it or what I should be looking for. 
:-S  Does this sound familiar to anyone else?

-Sandra

Re: [Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Richard Henderson]

On 8/27/19 5:26 PM, Sandra Loosemore wrote:
> Yesterday I tried to build the recent 4.1 release system-mode QEMU for
> aarch64-none-elf and ran into a compilation error in
> ./contrib/libvhost-user/libvhost-user.c.

Why are you attempting to compile qemu for a non-hosted (aka bare metal)
configuration?  That is certainly not a supported thing to do.  We require
POSIX (or Win32) at a minimum.

I can only presume that you're intending a hosted configuration, and using a
cross-compiler that doesn't actually match up.  What is the intended host (and
libc if this is for Linux, since there are at least 3)?

> It's complaining about
> MADV_NOHUGEPAGE not being defined.  I'm not familiar with that code or even
> what it does; should that bit of logic be made conditional on MADV_NOHUGEPAGE
> being defined, or is this indicative of a configuration error for this target? 

I'm leaning toward the latter, but you're not giving much in the way of a hint.


r~

Re: [Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Sandra Loosemore]

On 8/27/19 6:39 PM, Richard Henderson wrote:
> On 8/27/19 5:26 PM, Sandra Loosemore wrote:
>> Yesterday I tried to build the recent 4.1 release system-mode QEMU for
>> aarch64-none-elf and ran into a compilation error in
>> ./contrib/libvhost-user/libvhost-user.c.
> 
> Why are you attempting to compile qemu for a non-hosted (aka bare metal)
> configuration?  That is certainly not a supported thing to do.  We require
> POSIX (or Win32) at a minimum.
> 
> I can only presume that you're intending a hosted configuration, and using a
> cross-compiler that doesn't actually match up.  What is the intended host (and
> libc if this is for Linux, since there are at least 3)?

Sorry if that was not clear.  The target is aarch64-none-elf with the 
provided semihosting facilities in QEMU.  The host is x86_64-linux-gnu. 
We deliberately link against a pretty old glibc sysroot (looks like 
version 2.11.1), but we did that for last year's 3.0 release as well, 
and haven't made any other changes in the configure options etc that we 
use to build QEMU for this target.

-Sandra

Re: [Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Richard Henderson]

On 8/27/19 6:42 PM, Sandra Loosemore wrote:
> Sorry if that was not clear.  The target is aarch64-none-elf with the provided
> semihosting facilities in QEMU.  The host is x86_64-linux-gnu. We deliberately
> link against a pretty old glibc sysroot (looks like version 2.11.1), but we did
> that for last year's 3.0 release as well, and haven't made any other changes in
> the configure options etc that we use to build QEMU for this target.

Still not clear.

The combination "glibc" and "qemu semihosting" doesn't make sense.  The triplet
"aarch64-none-elf" is a gcc thing and has no referent in qemu.

Are you building qemu-system-aarch64 for x86_64-linux, using an old x86_64 sysroot?

In any case, glibc 2.11.1 is definitely out of support.  Even CentOS 6 used
2.12 and we don't support that anymore either.  Of the current
long-term-support distros, I believe the oldest version of glibc is CentOS 7
with 2.17.

As recently mentioned in

  https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg04514.html

we may accept a small patch with a large comment, but there are no guarantees
how long we will keep such workarounds.

I encourage you to re-examine why you're carrying around a 10 year old glibc.


r~

Re: [Qemu-devel] libvhost-user: undefined reference to MADV_NOHUGEPAGE

[Sandra Loosemore]

On 8/27/19 9:01 PM, Richard Henderson wrote:
> On 8/27/19 6:42 PM, Sandra Loosemore wrote:
>> Sorry if that was not clear.  The target is aarch64-none-elf with the provided
>> semihosting facilities in QEMU.  The host is x86_64-linux-gnu. We deliberately
>> link against a pretty old glibc sysroot (looks like version 2.11.1), but we did
>> that for last year's 3.0 release as well, and haven't made any other changes in
>> the configure options etc that we use to build QEMU for this target.
> 
> Still not clear.
> 
> The combination "glibc" and "qemu semihosting" doesn't make sense.  The triplet
> "aarch64-none-elf" is a gcc thing and has no referent in qemu.
> 
> Are you building qemu-system-aarch64 for x86_64-linux, using an old x86_64 sysroot?

Yes.  We only use this configuration of QEMU as an instruction-set 
simulator so that we can test cross-compilers and gdb for bare-metal 
aarch64-none-elf target, using newlib as the target C library and the 
GDB semihosting support in QEMU for low-level fileio primitives.

BTW, I did not run into this undefined-symbol error when building the 
equivalent configuration for bare-metal nios2-elf target with the same 
sysroot and host setup.  That target does not build libvhost-user at all.

> In any case, glibc 2.11.1 is definitely out of support.  Even CentOS 6 used
> 2.12 and we don't support that anymore either.  Of the current
> long-term-support distros, I believe the oldest version of glibc is CentOS 7
> with 2.17.
> 
> As recently mentioned in
> 
>    https://lists.gnu.org/archive/html/qemu-devel/2019-08/msg04514.html
> 
> we may accept a small patch with a large comment, but there are no guarantees
> how long we will keep such workarounds.

I wouldn't mind just applying a local patch to fix the build.  What I'm 
really trying to do is just get help in understanding what broke this, 
so I can come up with such a patch to un-break it again.

> I encourage you to re-examine why you're carrying around a 10 year old glibc.

We update our host build environment infrequently, and we've still had 
customers requiring CentOS 6 support until quite recently.

-Sandra