From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:38757) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbRHW-0006ET-Ag for qemu-devel@nongnu.org; Thu, 22 Nov 2012 02:33:08 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TbRHU-0007qS-NW for qemu-devel@nongnu.org; Thu, 22 Nov 2012 02:33:06 -0500 Received: from mx1.redhat.com ([209.132.183.28]:16620) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TbRHU-0007q9-G2 for qemu-devel@nongnu.org; Thu, 22 Nov 2012 02:33:04 -0500 Date: Thu, 22 Nov 2012 08:33:00 +0100 From: Stefan Hajnoczi Message-ID: <20121122073300.GA7398@stefanha-thinkpad.redhat.com> References: <1353492752-16084-1-git-send-email-stefanha@redhat.com> <1353492752-16084-3-git-send-email-stefanha@redhat.com> <50AD2AA4.1070106@weilnetz.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50AD2AA4.1070106@weilnetz.de> Subject: Re: [Qemu-devel] [PATCH 2/5] vdi: don't override libuuid symbols List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Weil Cc: Kevin Wolf , Anthony Liguori , qemu-devel@nongnu.org On Wed, Nov 21, 2012 at 08:25:24PM +0100, Stefan Weil wrote: > Am 21.11.2012 11:12, schrieb Stefan Hajnoczi: > >It's poor symbol hygiene to provide a global symbols that collide with a > >common library like libuuid. If QEMU links against a shared library > >that depends on uuid_generate() it can end up calling our stub version > >of the function. > > > >This exact scenario happened with GlusterFS libgfapi.so, which depends > >on libglusterfs.so's uuid_generate(). > > > >Scope the uuid stubs for vdi.c only and avoid affecting other shared > >objects. > > > >Signed-off-by: Stefan Hajnoczi > >Reviewed-by: Kevin Wolf > >--- > > block/vdi.c | 9 +++------ > > 1 file changed, 3 insertions(+), 6 deletions(-) > > > > > Hi Stefan, > > I'm not opposed to this patch but would like to better understand > the problem which you had with the old solution. > > Does libglusterfs.so really have a uuid_generate? Why does it not > take the implementation from libuuid.so? Then QEMU could also > use libuuid.so, and there would be no problem at all. > > I tried to reproduce the problem but could not find a libgfapi.so > in the Debian or Ubuntu package archives. libgfapi.so is only in glusterfs.git/master. It has not yet been available in a release. The problem occurs when QEMU and GlusterFS are built on a system without the libuuid.h development header. QEMU's behavior in this situation is to build our own libuuid stubs in block/vdi.c. The symbols are global. GlusterFS's behavior in this situation is to build with its own libuuid implementation. The symbols are global in libglusterfs.so. The libgfapi.so shared object links against libglusterfs.so and expects its uuid_generate() symbol to be resolved. The fun happens when using QEMU block/gluster.c and it calls into libgfapi.so. It seems QEMU's block/vdi.c libuuid stubs are bound and GlusterFS is now calling QEMU's dummy code - uuid_generate() always returns the zero UUID! Both QEMU and GlusterFS should not provide global symbols for a common library. Stefan