<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#3333FF">
    <div class="moz-cite-prefix">Roumen<br>
      <br>
      Thank you, but - with my "commenting out the rm" hack - I seem to
      have achieved success (and many, many thanks to you and others who
      have helped).<br>
      <br>
      More than just success - I have made my changes (tiny really) in
      the approximate fashion suggested by Aleksey (I implemented a
      sub-set of callbacks for dealing with "cid:" prefixed references
      and registered them in xmlSecIORegisterDefaultCallbacks in
      xmlsec's io.c module - only a sub-set, because only the "match"
      and "open" functions needed to differ from the standard "File"
      callbacks).  I have that working and it is now doing what I
      needed: placing digests of both the SOAP document itself, and the
      referenced XML "payload" document into the SignedInfo Reference
      elements of the SOAP document before creating the digital
      signature and putting that in the SignatureValue element.<br>
      <br>
      The crucial thing for me is that it appears to pass muster with
      the system I am sending it to as a valid signature.<br>
      <br>
      I will, when I have time (project completed - invoice sent), write
      up the whole procedure I used to build all of the libraries (zlib,
      iconv, openssl, libxml2, libxslt and xmlsec) from the ground up in
      MinGW/MSys as a reference for the future and post a link to it
      here.  I am sure that I have not done it the best way, but at
      least I have got it to work (which, while only a small virtue, is
      an important one... to me at least <g>).<br>
      <br>
      Thank you all again!<br>
      <br>
      Mike<br>
      <br>
      On 10/02/2013 14:39, Roumen Petrov wrote:<br>
    </div>
    <blockquote cite="mid:5117B129.2080501@roumenpetrov.info"
      type="cite">Mike Peat wrote:
      <br>
      <blockquote type="cite">Hi Roumen
        <br>
        <br>
        [SNIP]
        <br>
        //===================
        <br>
        ...
        <br>
        make[5]: Entering directory
        `/projects/xmlsec1/xmlsec1-1.2.18/include/xmlsec'
        <br>
----------------------------------------------------------------------
        <br>
        <br>
        *** WARNING ***:
        <br>
        <br>
        You seem to have old xmlsec header files installed in:
        <br>
        <br>
          "/projects/xmlsec1/xmlsec1-1.2.18/include/xmlsec"
        <br>
      </blockquote>
      This is old default location : $(includedir)/xmlsec
      <br>
      <br>
      <br>
      <blockquote type="cite">
        <br>
        The entire directory will be removed now.
        <br>
        To allow parallel installation of different xmlsec library
        versions,
        <br>
        the header files are now installed in a version specific
        subdirectory:
        <br>
        <br>
          "/projects/xmlsec1/xmlsec1-1.2.18/include/xmlsec1/xmlsec"
        <br>
      </blockquote>
      , i.e. new one is is $(includedir)/xmlsec1/xmlsec. Note extra
      subdirectory 'xmlsec1' in path.
      <br>
      <br>
      <blockquote type="cite">
        <br>
----------------------------------------------------------------------
        <br>
        <br>
        rm: cannot remove directory
        `/projects/xmlsec1/xmlsec1-1.2.18/include/xmlsec': Permission
        denied
        <br>
      </blockquote>
      I think this is windows limitation - a process still use old
      header location or race condition from antivirus or ....
      <br>
      May be for details you would like to review cygwin implementation
      of removal commands and hacks for microsoft OS-es.
      <br>
      <br>
      <blockquote type="cite">[SNIP]
        <br>
      </blockquote>
      xmlsecincdir = $(includedir)/xmlsec1/xmlsec
      <br>
      <br>
      <blockquote type="cite">...
        <br>
        remove-old-headers:
        <br>
            @if test "x$(DESTDIR)" = "x" && test -d
        "$(includedir)/xmlsec"; then \
        <br>
        [SNIP]
        <br>
                echo "  \"$(xmlsecincdir)\""; \
        <br>
        [SNIP]
        <br>
                rm -rf "$(includedir)/xmlsec"; \
        <br>
            fi
        <br>
        [SNIP]
        <br>
        <br>
        My workaround was just to comment-out the "rm" line, which
        resulted in workingness.
        <br>
      </blockquote>
      <br>
      <blockquote type="cite">I suspect that this is an actual bug
        rather than an aspect of my stupidity.
        <br>
      </blockquote>
      I don't know why in you environment exists
      .../xmlsec1-1.2.18/include/xmlsec.
      <br>
      This is not real issue (see above old vs new location).
      <br>
      <br>
      May be one minus before remove commands just to ignore results is
      enough.
      <br>
      <br>
      If I'm right for race in recursive removal then after reboot OLD
      directory  won't exists.
      <br>
      <br>
      <blockquote type="cite">Mike
        <br>
      </blockquote>
      [SNIP]
      <br>
      <br>
      Roumen
      <br>
      <br>
      .
      <br>
      <br>
    </blockquote>
    <br>
  </body>
</html>