Issue 104856

*** Issue 105175 has been marked as a duplicate of this issue. ***

Done in xmlsec_1_2_12. 

Preliminary reports are that that the efforts in xmlsec_1_2_12 are at least
plausible. I'll hand this task over to you now for sanity testing

cc

I have moved the scp2 and libxmlsec changes to CWS jl135_nss which also contains
the updated nss. 

@cmc: I am going to delete the cws xmlsec1_2_12 if you do not mind. Thanks for
the patches.

Target 3.2

@tono & cmc: configure failed on Mac (buildbot termite and internal machines):

checking for nspr libraries >= 4.0... ./configure: line 26177: test: too many
arguments
no
checking for nss libraries >= 3.2... ./configure: line 26263: test: too many
arguments
no
checking for gnutls libraries >= 0.8.1... no
checking for mscrypto libraries... none
checking for crypto library... configure: error: At least one crypto library
should exist for xmlsec1
dmake:  Error code 1, while making
'./unxmacxi.pro/misc/build/so_configured_so_xmlsec1'

I fixed it by using the line which I found in the configure of the old libxmlsec:

@@ -26062,7 +26174,7 @@
 	done
 
 	for dir in $ac_nss_lib_dir ; do
-    	    if test -f $dir/libnspr4$shrext ; then
+            if test -f $dir/libnspr4.so -o -f $dir/libnspr4.dylib ; then
 		        	if test "z$dir" = "z/usr/lib" ; then
             	    NSPR_LIBS="$NSPR_LIBS_LIST"
     		else
@@ -26148,7 +26260,8 @@
         done
 
         for dir in $ac_nss_lib_dir ; do
-    	    if test -f $dir/libnss3$shrext ; then
+            if test -f $dir/libnss3.so -o -f $dir/libnss3.dylib ; then
+
         	    		if test "z$dir" = "z/usr/lib" ; then
         	    NSS_LIBS="$NSS_LIBS_LIST"
                 else

This change is in libxmlsec/xmlsec1-configure.patch  of cws jl135_nss, r 276405.
$shrext expands to 
$(test .$module = .yes && echo .so || echo .dylib)
and $module is yes. 
This seams to be strange as the extension of the nss libraries is .dylib an not .so.

I am not quite comfortable with all this configure stuff and would be happy if
you could have a quick look. The builds on mac,windows,linux are ok with this
change.

By the way, I adapted the mingw patch, because this change caused the patch to
fail when it was applied.

The trick with a "configure" is that its generated from the matching
configure.in with "autoconf". Typically a configure is unreadable goo, and
changes dramatically depending on the version of autoconf used to generate it,
so getting the exact old version of autoconf used to make it keeps the diffs
down to readable levels is the best approach. Manual editing of the configure to
get a small diff is alright by me personally as long as the configure.in has the
"real" change in it.

I'll attach here a little example update for the toplevel configure patch to
merge in the mac changes made in configure. The mingw32 bit probably needs a
little love to get its configure.in back in sync with the configure change. 

Maybe the better thing to do is to put the first patch and the mingw32 patch
back the way it before the mac specific changes. And add another maxosx.patch at
the end that applies after the generic configuration patch and after the mingw32
one.

Created attachment 64923 [details]
patch to a patch to demo matching input configure.in changes to the output configure :-)

Thanks. I have changed the configure.in as suggested and updated 
xmlsec1-configure.patch, xmlsec1-mingw32.patch.

@hi: Please verify.

This is more an developer issue. 
I can only say that I've not found any regression so far.

.

.