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

[Michael Tokarev <mjt@tls.msk.ru>]

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
statically.

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
mutex.

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
commit...

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

Thanks,

/mjt

> 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(-)
>