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

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

[Rehashing a previous thread]

19.06.2013 20:58, Paolo Bonzini wrote:
> Il 18/06/2013 19:34, Michael Tokarev ha scritto:
>> 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 took block/curl.o as an example (in the last patch).
>>
>> This is a working example which can be used as is as a starting point
>> to convert other similar cases.
> 
> I was thinking of this problem too while drafting the modules feature
> page.  My solution had some duplication:
> 
> libs-$(CONFIG_CURL) += $(CURL_LIBS)
> $(obj)/curl.so: libs-$(CONFIG_CURL) += $(CURL_LIBS)
> 
> where the .so rule would use $(libs-y) $(libs-m).
> 
>> 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.
> 
> I like this solution, and I agree that consistency between cflags and
> libs is good.  However, it would be great if you could do it without
> changing the meaning of $(obj).  It is not clear to me (from reading the
> patches) why you need that.
> 
> Also, for the inevitable bikeshedding, I would prefer
> 
>    cflags-$(obj)/curl.o-y
>    libs-$(obj)/curl.o-y

There's no need to have -y or -n prefix here, at least for now,
because a) it does look ugly -- this is what we have to actually
specify in makefile, and b) we don't really need to have different
libs for static vs dynamic linking or flags.  I think anyway.

Also, my version (which uses $(obj)/curl.{libs,cflags,mod}) is safer
because the names will not clash with each other.

>> 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.
> 
> The ../ is ugly indeed.  Perhaps we can instead use something like
> 
> common.o: $(patsubst %,../%, $(common-obj-y))
> 	$(LD) -r -o $@ $^
> 
> and then link common.o into the QEMU target.  Libtool can also be used
> to abstract "ld -r".  Making libtool mandatory wouldn't be a problem IMO
> (we'd need it anyway for modules) as long as you do not need libtool to
> start QEMU or gdb from the build directory.

I think this will mean that whole common.o will have to be linked
into each executable which uses it, even if some executables are
only using just one function from whole lot of .o files.

And I think we don't really have a choice here BUT to actually build a
shared library with all this stuff, which will be loaded either by
qemu-system binary or by tools (or by qemu-user for that matter) --
it looks like the only sane way to get all required-for-plugins symbols
is to use a shared library.

The same mechanism can be used to build .a static library too, so there
will be no different rules for plugins-vs-non-plugins cases.

And if foo.so or foo.a library is built, all the foo.libs of all
objects/modules which are members of that library, can be combined
into ${fooo.libs} just as well.

Thanks,

/mjt