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
