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