Sorry, no ideas. I was never able to compile xmlsec with MinGW for various reasons.
Aleksey On 10/11/12 10:35 AM, Mike Peat wrote: > Hi Aleksey > > Not quite as great as I had thought I'm afraid. :-( > > When I went to run my shiny new xmlsec on the target platform it wanted > msvcr100.dll. I gave it that, but it then turned out that my version was > crashing (quietly - I had to look into the Windows Event Log to discover > what was going on) with a problem in ntdll.dll. > > I remembered the note in the README that pointed out that all the code > had to use exactly the same version of the MS C runtime and suspected > that the other libraries were using msvcrt.dll rather than the "100" > version (10.0 - I was using Visual Studio 2010) my code wanted. I tried > using older versions of Visual Studio to do the build (picture a lot of > thumb-twiddling while I installed version after version of it <g>), but > that was no real help: VS6 failed to understand a lot of the code; > VS2003 had just a couple of things it was unhappy about; VS2005 compiled > and built it all OK, but on running on the target it wanted > msvcr80.dll... which of course resulted in the same silent runtime crash > in ntdll.dll. > > So I have now given up on Microsoft and switched to using MinGW as a > build environment. After a bit of fighting to discover the right way to > configure it and get to to start building, it is now coming up with an > error during the make which I really don't understand: > > dl.c: In function 'xmlSecCryptoDLLibraryConstructFilename': > dl.c:295:30: error: 'PACKAGE' undeclared (first use in this function) > dl.c:295:30: note: each undeclared identifier is reported only once > for each fun > ction it appears in > make[3]: *** [dl.lo] Error 1 > > > ...and bombs out. > > The line (295) in dl.c that is causing the problem (in > xmlSecCryptoDLLibraryConstructFilename) is: > > len = xmlStrlen(BAD_CAST PACKAGE) + xmlStrlen(name) + > xmlStrlen(tmpl) + 1; > > > and it has a /* TODO */ comment in front of it. > > I am a bit stumped. Obviously I have some aspect of the configuration > wrong, since the same code built OK under Visual Studio, but I have no > idea just what in order to start fixing it. > > One thing is a bit messy about how I am doing things: I couldn't get the > configure script to work out where I had put xmllib2, so in the end I > put the source version of that in there and told it about that instead > (via "--with-libxml-src") and it appeared to build that without a > problem. However I now note (in looking for any occurrence of "PACKAGE" > - there are quite a few: almost 7,000!) that "acconfig.h" in libxml2 has > an "#undef PACKAGE" statement in it, while its "config.h.in" has a > couple of them, and am wondering if that could somehow be to blame. > (Probably not, but it is the sort of thought I have when I have no idea > what is actually going on.) > > Any thoughts would be much appreciated. > > TIA > > Mike > > On 04/10/2012 15:06, Aleksey Sanin wrote: >> Great! Actually I suggest to do it 'the right way' and simply >> create 'cid' protocol handlers: >> >> http://www.aleksey.com/xmlsec/api/xmlsec-io.html#XMLSECIOREGISTERCALLBACKS >> >> >> Aleksey >> >> On 10/4/12 5:43 AM, Mike Peat wrote: >>> Aleksey >>> >>> Just to let you know that I have (finally!) cracked it and got xmlsec to >>> build and run on Windows (and even with an addendum to your copyright >>> notice that indicates that it is my own bodged version! <g>). >>> >>> Now I just have to work out how to modify it (in >>> xmlSecTransformInputURIOpen I think...) to strip off any leading "cid:" >>> from the URI. >>> >>> Thank you for your help! >>> >>> Mike >>> >>> On 21/09/2012 05:02, Aleksey Sanin wrote: >>>> Mike, >>>> >>>> You will need to look into win32/ folder and use Microsoft C compiler. >>>> Honestly, I haven't touched Windows for years so it will be hard for >>>> me to give you a better advice. >>>> >>>> Another option is of course to use a VM with linux and just run it >>>> through VM. >>>> >>>> Aleksey >>>> >>>> On 9/20/12 6:53 AM, Mike Peat wrote: >>>>> Thanks for that Aleksey >>>>> >>>>> Initially I thought I had found a work-around, but I am now back looking >>>>> at the problem from square one again. Let me explain... >>>>> >>>>> Another customer of the organisation I am communicating with was using >>>>> xmlsec at the command-line to do this, which is what led me down this >>>>> route initially. >>>>> >>>>> It turns out that if the document (file) referred to in the <Reference> >>>>> URI attribute is in the _same directory_ as the SOAP document being >>>>> signed, xmlsec actually picks it up OK and includes its hash-value in >>>>> the <Reference> -> <DigestValue> element... problem solved! >>>>> (Apparently...) However, life is not so simple. >>>>> >>>>> They are working on a Linux system, while I am cursed with being in >>>>> Windows. :-( >>>>> >>>>> They are thus able to have files named "cid:/xxxxxxx/", while I am not >>>>> (no colons allowed in file-names in Windows!). So I changed the URI >>>>> attribute in my Reference element to just contain a file-name with no >>>>> "cid:" prefix, and that got things working as far as digitally signing >>>>> the whole thing with xmlsec was concerned. However now I am getting >>>>> messages through to the other party's back-end system, which are being >>>>> rejected because now _it_ can't identify the referred to document: it >>>>> seems that it insists on using that "cid:" scheme. >>>>> >>>>> So... >>>>> >>>>> I need to persuade xmlsec to recognise that "cid:" prefix and, in >>>>> effect, ignore it (if the referred-to file-name starts with "cid:", >>>>> replace that with nothing prior to trying to open the file). >>>>> >>>>> I have got the xmlsec source, but up until now have just been using Igor >>>>> Zlatkovic's Windows binaries. >>>>> >>>>> I need to (a) get xmlsec to compile in a Win32 environment and (b) know >>>>> where to make the changes in xmlsec (or perhaps one of its libraries) in >>>>> order to create a version which will do what I need. >>>>> >>>>> I am not really a C/C++ programmer, but I can usually get by in pretty >>>>> much anything (I have been programming since about 1972 - Oh Lord! >>>>> That's 40 years! I'm getting too old for this!). >>>>> >>>>> What compiler will I need and where do I find the code I will need to >>>>> change? And what build process do I need to go through? Is there a >>>>> make file or something similar? >>>>> >>>>> Alternatively... what would it take to get somebody who actually knows >>>>> what (s)he is doing to do this for us? We don't have much in the way of >>>>> budget, but this is stopping a project that has months of work in it >>>>> dead in its tracks right now, so... >>>>> >>>>> TIA >>>>> >>>>> Mike Peat >>>>> >>>>> On 14/09/2012 16:57, Aleksey Sanin wrote: >>>>>> Mike, >>>>>> >>>>>> You will probably need to write code to support "cid" URL scheme >>>>>> and resolve references correctly to the MIME attachments: >>>>>> >>>>>> http://www.aleksey.com/xmlsec/api/xmlsec-io.html >>>>>> >>>>>> Aleksey >>>>>> >>>>>> On 9/14/12 7:50 AM, Mike Peat wrote: >>>>>>> Hi >>>>>>> >>>>>>> I am using xmlsec at the command line in an ebXML application. As you >>>>>>> probably know, ebXML uses SOAP-with-attachments (over HTTP) to send its >>>>>>> messages. The message thus consists of multipart-MIME content in the >>>>>>> HTTP body: the first part being a SOAP document containing (among other >>>>>>> things) the Signature stuff and the second being an XML document which >>>>>>> is the business payload. >>>>>>> >>>>>>> The Signature->SignedInfo in the SOAP document needs to contain two >>>>>>> <Reference> elements: one for the SOAP document itself (URI="") and one >>>>>>> for the payload XML (URI="cid:xxxxxxxx", where "xxxxxxxx" is the content >>>>>>> ID of the second MIME part). >>>>>>> >>>>>>> I am managing to successfully sign simple SOAP messages with no payload >>>>>>> (and hence no second <Reference> element), but I just can't work out how >>>>>>> to get xmlsec to sign both documents together. I have tried many >>>>>>> different ways, but to no avail. I am sure I am missing something >>>>>>> simple, but... :-( >>>>>>> >>>>>>> Any help would be very much appreciated - I've been banging my head off >>>>>>> this brick wall for a week... and it is starting to really hurt! :-( >>>>>>> (That takes a while, because my brain is so dense, but even it starts >>>>>>> gets sore eventually!) >>>>>>> >>>>>>> TIA >>>>>>> >>>>>>> Mike Peat _______________________________________________ >>>>>>> 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
