qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Bug 902306] [NEW] qemu-user -static variants require s


From: Vagrant Cascadian
Subject: Re: [Qemu-devel] [Bug 902306] [NEW] qemu-user -static variants require shared libraries
Date: Fri, 16 Dec 2011 21:17:38 -0000

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

-- 
You received this bug notification because you are a member of qemu-
devel-ml, which is subscribed to QEMU.
https://bugs.launchpad.net/bugs/902306

Title:
  qemu-user -static variants require shared libraries

Status in QEMU:
  New
Status in “qemu” package in Debian:
  New

Bug description:
  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

To manage notifications about this bug go to:
https://bugs.launchpad.net/qemu/+bug/902306/+subscriptions



reply via email to

[Prev in Thread] Current Thread [Next in Thread]