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

Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 package?



´╗┐good idea. What about a prefix like "vir_" ?

--------------------------------------------------
From: "Matthias Bolte" <matthias bolte googlemail com>
Sent: Monday, December 20, 2010 4:03 PM
To: <arnaud champion devatom fr>
Cc: "Justin Clift" <jclift redhat com>; "libvir-list libvirt" <libvir-list redhat com>
Subject: Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 package?

That's correct, regsvr32 is for registering COM components. It has
nothing to do with the runtime linker finding the DLLs.

In order to have libvirt-0.dll available for applications it must
either be in the same directory as the application's binary (having it
in the working directory might work too), or it must be in the PATH.

But putting \bin in the PATH pollutes the global DLL namespace with
common DLLs like zlib1.dll. This makes DLL hell worse. Strawberry Perl
avoids this by making the DLL name unique to Strawberry Perl by
posfixing them with an underscore.

I just hacked a small C program that can rewrite the DLL import
tables. This allows to easily prefix all DLLs in \bin (expect
libvirt-0.dll and libvirt-qemu-0.dll) without touching all the
buildsystems for those DLLs to rename them.

Instead of this filenames in \bin:

iconv.dll
intl.dll
libcurl-4.dll
libgcrypt-11.dll
libgnutls-26.dll
libgpg-error-0.dll
libportablexdr-0.dll
libtasn1-3.dll
libvirt-0.dll
libvirt-qemu-0.dll
libxml2-2.dll
virsh.exe
zlib1.dll

we can have this ones:

libvirt-0.dll
libvirt-qemu-0.dll
virsh.exe
_lv_iconv.dll
_lv_intl.dll
_lv_libcurl-4.dll
_lv_libgcrypt-11.dll
_lv_libgnutls-26.dll
_lv_libgpg-error-0.dll
_lv_libportablexdr-0.dll
_lv_libtasn1-3.dll
_lv_libxml2-2.dll
_lv_zlib1.dll

Or with any other prefix/postfix with up to 4 characters.

Matthias

2010/12/20  <arnaud champion devatom fr>:
?Hi Justin,

I don't think regsvr32 will work, as I know, regsvr32 is used to register
COM components against registry, and these dlls are not COM compatible.

Arnaud

--------------------------------------------------
From: "Justin Clift" <jclift redhat com>
Sent: Monday, December 20, 2010 6:27 AM
To: "Arnaud Champion" <arnaud champion devatom fr>
Cc: "libvir-list libvirt" <libvir-list redhat com>
Subject: Re: [libvirt] Got time to try out the libvirt 0.8.6 win32 package?

On 12/12/2010, at 9:50 PM, <arnaud champion devatom fr>
<arnaud champion devatom fr> wrote:

Maybe a suggestion (don't know if it is pertinent or not) : when I have
tried C# bindings, I must copy libvirt binaries dll in the C# bindings
directory, so maybe it can be a good idea to add the install path of the /bin dll directory to the PATH environment variable, in this way, no more
need to copy dlls.

With this specific problem, do you know if "registering" the dll's be the
right approach?

Something like:

   regsvr32.exe /s iconv.dll
   regsvr32.exe /s intl.dll
   regsvr32.exe /s libcurl-4.dll
   regsvr32.exe /s libgcrypt-11.dll
   regsvr32.exe /s libgnutls-26.dll
   regsvr32.exe /s libgpg-error-0.dll
   regsvr32.exe /s libportablexdr-0.dll
   regsvr32.exe /s libtasn1-3.dll
   regsvr32.exe /s libvirt-0.dll
   regsvr32.exe /s libvirt-qemu-0.dll
   regsvr32.exe /s libxml2-2.dll
   regsvr32.exe /s zlib1.dll

(probably with the path names though)

I'm kind of thinking it's the right idea, but am concerned about conflict
other applications that might
be using the same libraries (zlib1.dll for example).

Any ideas?

Regards and best wishes,

Justin Clift


--
libvir-list mailing list
libvir-list redhat com
https://www.redhat.com/mailman/listinfo/libvir-list




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