|
>Thanks for info. Why one needs static for DLL is beyond me. Why not use DLL for libxml2 if using DLL distribution – nobody will be updating your application and with a DLL they could update libxml2 … ouch.
I always use static with >static – like I care that the application is a little bigger and more importantly they can use whatever libxml2 they want and I don’t care. Plus in large Unix environments this is very efficient
as AIX (my primary) only loads a program >once. Then it is in memory and everyone uses it. If nobody is using it, it goes away and if it is not used often … who cares. You also have the advantage of not smacking any libxml2
they might have. I rarely have had a problem with >libxml2 as dynamic (except Linux that can’t make a static to save itself) but I still have static. Openssl and stunnel are much more likely to be trashed by the user.
And SSH use these so conflicting libraries can trash your connectivity. At
>the very least, if you have to use DLLs then put them in your application directory with instructions to user that if they “want” to trash your library move to whatever directory … then you are still pretty safe. > Our users are developers and generally prefer to have everything in a single DLL. And I don’t have the option of distributing our DLL without linking libxml2 statically.
In any case, the issue with the TLSAlloc leak happens with a static library as well. A developer using our static library linked into their own DLL that is dynamically loaded and unloaded by an application will be missing the TLSFree call. But building with LIBXML_STATIC_FOR_DLL defined allows the TLSFree to be called
when xmlCleanupParser() is called. I’m fine using this build of the library as long as it will not cause issues in our other configurations. I don’t think it will and I will be doing some testing this week to verify, but I was hoping for a confirmation here. >As to your final question – I am not sure that it is safe. Not so expert with Windows. But generally I have found with libxml2 is that if they have a setting it is for a reason – and using it in other cases
is not safe. I would go on that >assumption unless someone more expert on Windows tells you I am wrong (happens a lot
J but I have used libxml2 on a ten O/S or so including Windows for decades since it was libxml – no two – and found it reliable and safe it you
>set it correctly). Thank you for the information. I will do testing this week and see if there are any issues. I was hoping someone had run into this previously and had some insight.
From: xml [mailto:xml-bounces gnome org]
On Behalf Of Dan Heinz I have a library that uses the static libxml2 library. My library is distributed in three ways: a DLL, a static library that has the libxml2 library merged, and a static library that does not have libxml2 merged. I have a Windows environment where my DLL is late-bound and being loaded and unloaded multiple times by an application using LoadLibrary and FreeLibrary. After 1088 iterations of loading and unloading my DLL, the thread local storage allocation
will fail (TLSAlloc) since it is not being freed by calling xmlCleanupParser. I see there is a define, LIBXML_STATIC_FOR_DLL, and a static build (libxml2_a_dll.lib) for this situation, and building and using this static library fixes the issue. Is it safe to use the libxml2 build with the LIBXML_STATIC_FOR_DLL defined in all my library configurations (DLL and static with libxml2 merged)? Is it safe to use when the DLL is early-bound? Is this build safe to use for non-Windows platforms? |