Re: [Qemu-devel] [RFC PATCH 0/4] per-object libraries

[Michael Tokarev]

18.06.2013 21:34, Michael Tokarev wrote:
> The following working patchset demonstrates a one step to plugins system:
> it moves various dependent libraries and stuff out from libs_softmmu or
> libs_tools to object-specific variables.  When that object is linked
> into final executable, corresponding libs are expanded and appended to
> the linking command line.

I also made a few more changes, to recognize "complex modules" which
consists of more than one .o file, and also added a few other minor
changes.

It is all available at

  http://git.corpit.ru/?p=qemu.git;a=shortlog;h=refs/heads/mjt-buildsys

> I took block/curl.o as an example (in the last patch).

It now also converts bluez.

Also, it uses qed as a "complex module" example.

> This is a working example which can be used as is as a starting point
> to convert other similar cases.
> 
> There are a few questions still.
> 
> I'm not sure whenever this $(obj)foo.o syntax (instead of $(obj)/foo.o)
> is okay, using the slash is more natural, but when you realize that
> objects can be stored in current dir it may be okay.  However, it is
> easy to make mistakes here in new code -- probably trivially catchable.
> 
> The foo.cflags isn't really necessary, but when you specify one
> thing one way (target-specific variable), and another thing completely
> different way, resulting code does not look nice.  In particular, the
> two curl definitions in block/Makefile.objs look somewhat funky if
> curl.cflags isn't used.
> 
> It is quite a bit ugly to strip out ../ in the link line, but it is
> also ugly to add that ../ in the first place.  Maybe I should add a
> comment in Makefile.target where it adds ../ to also refer to
> rules.mak, and back, for clarity.

It is not done anymore, but LINK command now accepts extra argument.
Both ways aren't nide.

> In configure, we may define $(obj)curl.libs directly, but for that
> to work we should know where exactly the curl.o is located.
> 
> At the same time, we may just as well use basenames (without paths)
> to define per-object variables -- this way we wont need to strip
> ./ from $(obj) or any other black magic, but we should ensure that
> all basenames are unique, or else bad things may happen.
> 
> When you build a library from an object, its libs aren't propagated.
> It is fixable, by creating library.libs variables and expanding them
> at executable link time, but since not all objects from the lib may
> be necessary, this isn't nice.
> 
> Generally, is is expected that obj.libs variables will be used only
> for common optional objects like "plugins".

The next step is to introduce common-obj-m and block-obj-m variables
to build the plugins.  This is almost trivial now, provided you
specify necessary extra_ldflags (-rdynamic -ldl), build in pie mode
(-pie), and have necessary changes applied to load the modules.

But I think additional stage is needed now: to also build some
shared library with all the common-obj and block-obj.  I'm not
sure supporing plugins without that shared library is a good idea,
but if we do, there are just too many variants (shared lib or not,
plugins or not).  In case shared library is in use, there's no
need to specify -rdynamic, either.  But shared lib will require
quite some more changes in the build system.

Thanks,

/mjt