[xmlsec] Re: problem encrypting when using Windows 2000 ?

Igor Zlatkovic igor at zlatkovic.com
Wed Jan 8 09:06:49 PST 2003 

Good Morning :-)

Of course you put everything in the FAQ. I shall put it online in the 
release notes section as well.

I would still gladly know if Meg's problem has been solved meanwhile?

Ciao,
Igor

Aleksey Sanin wrote:
> 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 at aleksey.com
>>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> xmlsec mailing list
>>> xmlsec at aleksey.com
>>> http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>>
>>
>> _______________________________________________
>> xmlsec mailing list
>> xmlsec at aleksey.com
>> http://www.aleksey.com/mailman/listinfo/xmlsec
> 
> 
> 
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec

More information about the xmlsec mailing list