[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 0/4] buildsys: Fix module build for block-iscsi.

From: Michael Tokarev
Subject: Re: [Qemu-devel] [PATCH 0/4] buildsys: Fix module build for block-iscsi.so
Date: Fri, 23 May 2014 13:59:00 +0400
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Icedove/24.5.0

23.05.2014 07:02, Fam Zheng wrote:
> We get:
>     $ qemu-img
>     Failed to open module: /home/fam/build/master/block-iscsi.so: undefined 
> symbol: bitmap_set
>     qemu-img: Not enough arguments
>     Try 'qemu-img --help' for more information
> Because since commit b03c38 (block/iscsi: speed up read for unallocated
> sectors), block/iscsi.c calls utils/bitmap.c:bitmap_* functions, which is not
> linked to qemu-img nor shared objects.

Heh. This is a very fun situation.

For the first time I've had it with postfix in about 2002,
when I tried to make postfix modular, and it didn't work,
because modules sometimes used symbols which are not present
in all executables who used the modules.

The solution is not link modules with missing symbols.  The
solution is to make libpostfix.so with all ths support functions,
and link all programs to it instead of using all support funcs

This is what has been done later in debian (they used simpler
approach, building 3 libs instead of one, because postfix had
3 utility libraries not 1).

Ofcourse in all cases, the soname included complete version
string, and the library was shipped in the main postfix
binary package, to avoid versioning problems.

Linking utility libraries into modules is dangerous, because
we may end up with having 2 definitions of the same symbol inside
one executable.  If that's a code part it's fine, -- both come
from the same build so the definition is the same.  But it that's
some global data section, we may have really interesting effects.
When one part of executable modifies one of the 2 global data
sections, and another part deals with another section.  Or
even more interesting -- when the same function first initializes
one mutex (in main executable), but later, after loading module,
will work with another, just loaded, incarnation of the same

The chance to have such a clash is small.  But once we'll hit
it, it will be _extremly_ difficult to debug situation.  And
ofcourse it'll be a smoking gun, -- we may actually have it
soon, but not noticing before much later, after some unrelated

So, I'd say, please do not follow this route.. ;)



> This series links module objects to libqemuutil.a. That requires -fPIC on the
> static library objects. The first patch unifies the dependency path of
> util-obj-y to libqemuutil.a by removing individual object list from
> libcacard-obj-y, so we can apply -fPIC from libqemuutils.a's object specific
> variables.
> Also added a travis build task for --enable-modules.
> Fam
> Fam Zheng (4):
>   Makefile: Link vscclient with libqemuutil.a and libqemustub.a
>   Makefile: Compile libqemustub.a and libqemuutil.a with -fPIC
>   rules.mak: Link DSO with libqemuutil.a
>   .travis.yml: Add a new build target with --enable-modules
>  .travis.yml        | 3 +++
>  Makefile           | 1 +
>  libcacard/Makefile | 9 ++-------
>  rules.mak          | 2 +-
>  4 files changed, 7 insertions(+), 8 deletions(-)

reply via email to

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