I was just about to write. I am trying to digest all of the great information. If I put the #defines in my code before the xmlsec headers, intestingly enough I get link errors (unresolved externals) on three variables which happen to be in the transforms.h header. Recall that the error message was about the transform. I also downloaded the libxmlsec-0.0.11.win32.v6 but got the same behavior as before (but without the #defines, since that doesn't even link for me).
We make all of our projects multithreaded dlls, btw. I will send source code if you still want to see it Igor ... Still broken :( meg Igor Zlatkovic wrote: > > 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 > >>>> [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 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Meg Morgan 425/739-2534 [EMAIL PROTECTED] http://www.votehere.net _______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
