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 [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
