[xmlsec] Re: problem encrypting when using Windows 2000 ?
Aleksey Sanin
aleksey@aleksey.com
Wed, 08 Jan 2003 08:28:28 -0800
Igor,
Thanks for long explanation! Will you mind if I add this to the FAQ?
I think this will be helpfull for people and save some time for us :)
Aleksey
Igor Zlatkovic wrote:
> 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
>
>
> _______________________________________________
> xmlsec mailing list
> xmlsec@aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec