[xmlsec] Re: problem encrypting when using Windows 2000 ?
Meg Morgan
meg@votehere.net
Wed, 08 Jan 2003 17:12:24 +0000
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
> >>>> 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
> >
> >
> >
> >
> > _______________________________________________
> > 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
--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Meg Morgan 425/739-2534
meg@votehere.net http://www.votehere.net