[xmlsec] Re: problem encrypting when using Windows 2000 ?
Igor Zlatkovic
xmlsec@aleksey.com
Wed, 08 Jan 2003 14:13:09 +0100
Hi Aleksey,
Those pointers being garbage is most often caused by static link without
#defining XMLSEC_STATIC. Another pitfall is using the wrong C runtime. It is
time for another lenghty explanation :-)
*STATIC Macros
--------------
When people link statically to libxmlsec, then they must #define
XMLSEC_STATIC in their source files before including any xmlsec header. I
observe, almost noone is doing that. This macro has no effect on Unix, but
it is vital on Windows.
This applies to libxml and libxslt as well, no matter if these are used
directly or not. If just libxmlsec is used, but everything is linked
statically, then there must be a
#define LIBXML_STATIC
#define LIBXSLT_STATIC
#define XMLSEC_STATIC
before any xmlsec header is included. Even if the client code doesn't call
into libxml at all, still this must be defined. Xmlsec headers will include
libxml headers and they must have these definitions. Without them, every
variable xmlsec includes from libxml headers will have __declspec(dllimport)
prepended and that will give headaches if static libxml is used for linking.
This scheme makes it possible to have any combination of static and dynamic
libraries in the resulting executable. Its cost is the need to #define
apropriate macros. People would ideally define them by using the compiler's
/D switch in projects that link statically.
Note that all this mess originates in MS linker and its inability to import
a variable from a DLL if that variable isn't declared with apropriate
declaration modifier. Since I cannot think of a good reason for the
existence of this requirement, I consider it a bug in MS linker.
MS C Runtime
------------
Windows basically has two C runtimes. The one is called libc.lib and can
only be linked to statically. The other is called msvcrt.dll and can only be
linked to dynamically. The first one occurs in its single-threaded and
multithreaded variant, which gives three different runtimes. These three
then live in their debug and release incarnations, which results in six C
runtimes, five of which are designed just to increase overall confusion :-)
The art is to choose the right one.
libxml, libxslt and libxmlsec, as I compile them, are all linked to
msvcrt.dll. The click-next click-finish wizardry from Visual Studio chooses
the single-threaded libc.lib as the default when you create a new project.
Using my binaries with that default is asking for trouble. The program will
crash as soon as the two runtimes meet.
The rule is simple. Exactly the same runtime must be used throughout the
application. Client code must use the same runtime as libxmlsec, libxml and
libxslt. This means, /MD compiler switch must be present when compiling
anything related to the binaries I provide. If someone needs a different
runtime for some reason, then the one must recompile not only libxmlsec, but
libxml and libxslt, perhaps even openssl as well.
Ciao,
Igor
Aleksey Sanin wrote:
> Igor,
>
> Thanks for looking into this! I believe that there is a problem with
> exporting pointers from dlls. In xmlsec I have static objects in the
> DLL and I export pointers to these objects. The error Meg and
> some other folks have is caused by the fact that these pointers are
> NULL in the application (or point to garbage in some cases).
> AFAIK, libxml and libxslt does not use such technique and there is
> no surprise that your binaries work just fine for these libraries :)
> When it's a simple and clear operation on *nix, it seems to be a problem
> on Windows because of the compiler(s), compiler options or whatever.
> I am working on fixing this but this will have to wait till the big new
> release because of binary compatibility issues.
>
> Aleksey
>
>
> Igor Zlatkovic wrote:
>
>> Hi Meg,
>>
>> I tried and tried, but wasn't able to reproduce that error.
>>
>> I use a slightly newer compiler than you do. As far as I know, the
>> binaries produced by that compiler are fully compatible with those
>> produced by VC 6. There should be no problems.
>>
>> However, there are some, obviously. Things might go good if you
>> recompile xmlsec with VC 6 but I fear that is not the root of the
>> problem. After all, libxml and libxslt binaries on my site are made
>> with the same compiler, are being downloaded fifty times a day in
>> average and many who use them do it with VC 6. The problem never
>> occured in a package other than xmlsec.
>>
>> I believe that the best way is to find the real source of the peril.
>> If it is in the xmlsec code, it must be fixed. If you did something
>> wrong in your code, then few others are obviously doing the same and
>> it should be discovered what that is. Finally, if the compiler is the
>> problem, then I'll start making binaries with VC 6.
>>
>> I have produced xmlsec 0.0.11 with VC 6 for you to test. You can get
>> it at
>> http://zlatkovic.com/projects/libxml/libxmlsec-0.0.11.win32.vc6.zip
>> Check if that one works.
>>
>> If you have code which demonstrates the error for me to use locally
>> for debugging, it would be very helpful.
>>
>> Ciao,
>> Igor
>>
>>
>> Meg Morgan wrote:
>>
>>> Greetings,
>>>
>>> I understand from Alexsey that this problem has been reported before.
>>> I am using your binaries and developing a windows application with
>>> MS Visual C++ 6.0. When I call xmlSecEncryptMemory I get an error:
>>>
>>> xmlSecTransformFind <..\src\transforms.c:331>: error 10: :
>>> href=http://www.w3.org/2001/04/xmlenc#tripledes-cbc
>>>
>>>
>>> Alexsey writes:
>>> "Let me guess, you are using Windows.
>>> Most likely you are using Igor's Windows binaries with MS VC 6.0.
>>> There were reported similar problems in this situation and the best
>>> advise I can give is to try to recompile everything by you "native"
>>> compiler."
>>>
>>> Is there any solution other than for me to compile under Windows myself?
>>>
>>> Thank you for your help,
>>> meg
>>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec@aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
>
>
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec@aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec