qemu-user -static variants require shared libraries

[Vagrant Cascadian]

somehwere in the qemu 1.0 series, the qemu-user static variants started issuing build warnings like so:

  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
  (.text+0xe37): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the gli
  bc version used for linking
  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
  (.text+0xe2a): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the gli
  bc version used for linking
  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
  (.text+0xe40): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the gli
  bc version used for linking
  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
  (.text+0xb7a): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the g
  libc version used for linking
  /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
  (.text+0xbbb): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the g
  libc version used for linking

for a full log, see:

https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1.0~rc4%2Bdfsg-1&stamp=1322591568

i've also tested with qemu/master from today (commit 217bfb445b54db618a30f3a39170bebd9fd9dbf2), and it has the same issue.

This seems to cause adduser, addgroup, etc. to fail in cross-architecture chroots that use statically built qemu-user binaries to emulate the foreign architecture.

Older versions (0.12-0.15, at least) didn't seem to have this issue.

live well,
  vagrant

[Michael Roth (mdroth)]

On 12/09/2011 01:39 PM, Vagrant Cascadian wrote:
> Public bug reported:
>
> somehwere in the qemu 1.0 series, the qemu-user static variants started
> issuing build warnings like so:
>
> /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> (.text+0xe37): warning: Using 'getpwuid' in statically linked applications requires at runtime the shared libraries from the gli
> bc version used for linking
> /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> (.text+0xe2a): warning: Using 'setpwent' in statically linked applications requires at runtime the shared libraries from the gli
> bc version used for linking
> /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> (.text+0xe40): warning: Using 'endpwent' in statically linked applications requires at runtime the shared libraries from the gli
> bc version used for linking
> /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> (.text+0xb7a): warning: Using 'getpwnam_r' in statically linked applications requires at runtime the shared libraries from the g
> libc version used for linking
> /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> (.text+0xbbb): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the g
> libc version used for linking
>
> for a full log, see:

We introduced a glib2.0 dependency in QEMU 0.15. I think this just a
result of glib introducing a much larger static build chain dependency.
I'm not sure if glib can be decoupled for usermode emulation, those it
at least seems to have escaped the malloc()->g_malloc() conversion so
maybe there were plans for that...

But currently at least it's considered a hard general dependency.

>
> https://buildd.debian.org/status/fetch.php?pkg=qemu&arch=amd64&ver=1.0~rc4%2Bdfsg-1&stamp=1322591568
>
> i've also tested with qemu/master from today (commit
> 217bfb445b54db618a30f3a39170bebd9fd9dbf2), and it has the same issue.
>
> This seems to cause adduser, addgroup, etc. to fail in cross-
> architecture chroots that use statically built qemu-user binaries to
> emulate the foreign architecture.
>
> Older versions (0.12-0.15, at least) didn't seem to have this issue.
>
> live well,
> vagrant
>
> ** Affects: qemu
> Importance: Undecided
> Status: New
>
> ** Affects: qemu (Debian)
> Importance: Unknown
> Status: Unknown
>
> ** Bug watch added: Debian Bug tracker #651083
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651083
>
> ** Also affects: qemu (Debian) via
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=651083
> Importance: Unknown
> Status: Unknown
>

[Vagrant Cascadian (vagrantc)]

On Fri, Dec 09, 2011 at 08:20:16PM -0000, Michael Roth wrote:
> On 12/09/2011 01:39 PM, Vagrant Cascadian wrote:
> > /usr/lib/gcc/i486-linux-gnu/4.6/../../../i386-linux-gnu/libglib-2.0.a(gutils.o): In function `g_get_any_init_do':
> > (.text+0xbbb): warning: Using 'getpwuid_r' in statically linked applications requires at runtime the shared libraries from the g
> > libc version used for linking
> >
> > for a full log, see:
>
> We introduced a glib2.0 dependency in QEMU 0.15. I think this just a
> result of glib introducing a much larger static build chain dependency.

it works fine with qemu 0.15.1, even when built with the same versions of
glib2.0 as as qemu 1.x branches. so that would seem a bit odd... unless qemu
1.x is using more of glib2.0 than qemu 0.15.

would that then essentially come down to tracking down all of glib2.0's build
dependencies and installing those as well?

> I'm not sure if glib can be decoupled for usermode emulation, those it
> at least seems to have escaped the malloc()->g_malloc() conversion so
> maybe there were plans for that...
>
> But currently at least it's considered a hard general dependency.

hrm. would like to see it working again, though it's a bit over my head.

live well,
  vagrant

[Peter Maydell (pmaydell)]

> This seems to cause adduser, addgroup, etc. to fail in cross-architecture chroots that use statically built qemu-user
> binaries to emulate the foreign architecture.

I just tried adduser in a chroot, and it worked OK. This is what I'd expect, because the glib function g_get_any_init_do is only called if we call any of the glib functions which want to know the user's username/fullname/home directory, and in fact we don't use those functions. So we don't end up calling the forbidden libc routines and the only issue is the ugly linker warnings.

[Peter Maydell (pmaydell)]

From comments on the linked Debian bug, the problems with adduser failing were actually due to missing prctl support, which is fixed by the two patch series:
http://patchwork.ozlabs.org/patch/139379/
http://patchwork.ozlabs.org/patch/139378/

So we can close this bug in qemu once those patches get into master. (I don't think we're ever going to be able to get rid of the linker warnings.)

[Peter Maydell (pmaydell)]

The prctl patches I mention in comment #4 went into upstream last year, so we can close this bug now.