qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] [PATCH v10 5/8] module: implement module loading


From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH v10 5/8] module: implement module loading
Date: Mon, 16 Sep 2013 13:08:11 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130805 Thunderbird/17.0.8

Il 16/09/2013 13:00, Alex Bligh ha scritto:
> 
> On 16 Sep 2013, at 11:38, Paolo Bonzini wrote:
> 
>> No, librbd does need to be there for the other symbols that are not weak
>> (e.g. rbd_aio_read).  This approach cannot be "taken to the limit", i.e.
>> removing the librbd dependency altogether.  For example:
>>
>> xx.c:
>> int f(void)
>> {
>>      return 42;
>> }
>>
>> yy.c:
>> #pragma weak f
>> extern int f(void);
>> int main()
>> {
>>      printf("%p %d", f, f ? f(): 67);
>> }
>>
>> $ gcc xx.c -shared -o xx.so
>> $ LD_RUN_PATH=$PWD gcc yy.c xx.so -o yy
>> $ ./yy
>> 0x4005b0 42
>> $ rm xx.so
>> $ ./yy
>> ./yy: error while loading shared libraries: xx.so: cannot open shared
>> object file: No such file or directory
> 
> I think you need to wrap f, i.e. take g as a pointer to f(), and
> call g().

No, you need to do dlopen("librbd.so"), which is bad because then
distros that can track .so dependencies will not do it anymore.
qemu-devel had a patch to do exactly that.

>> Also, the code _is_ ugly.  Do it once and it's perhaps acceptable.  Do
>> it for libiscsi, librbd, libcurl, libssh2, SPICE, GTK+, SDL etc. and it
>> becomes unmaintainable.
> 
> I agree it's ugly. However, it's pretty much the only way to cope
> with different versions of libraries.

But the reason to do modularization is not to "cope with different
versions of libraries".  In fact that's a problem that Fam's patches do
not solve at all.  The reason to do modularization is to make libraries
optional, i.e. let them be completely absent.

Paolo



reply via email to

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