Also, it would be nice to add a comment explaining which dll versions
these hashes are for.
2007/5/15, Tony Wu <[EMAIL PROTECTED]>:
here is a patch for checking both md5 :)
Index: make/depends.xml
===================================================================
--- make/depends.xml (revision 538045)
+++ make/depends.xml (working copy)
@@ -368,7 +368,10 @@
</antcall>
<checksum file="@{dest}" property="@{dest}.md5" />
<condition property="@{dest}.md5.verified" value="true">
- <equals arg1="[EMAIL PROTECTED]" arg2="@{md5}" />
+ <or>
+ <equals arg1="[EMAIL PROTECTED]" arg2="@{md5}" />
+ <equals arg1="[EMAIL PROTECTED]" arg2="@{md5}" />
+ </or>
</condition>
<antcall target="-remove-file-if-bad">
<param name="jar" value="@{dest}" />
Index: make/depends.properties
===================================================================
--- make/depends.properties (revision 538045)
+++ make/depends.properties (working copy)
@@ -43,6 +43,7 @@
msvcr.dll.file.x86=msvcr71.dll
msvcr.url.x86=file:///${hyenv.SystemRoot}/system32/msvcr71.dll
msvcr.md5.x86=86f1895ae8c5e8b17d99ece768a70732
+msvcr.md5.alternative=ca2f560921b7b8be1cf555a5a18d54c3
msvcr.dir.x86_64=${depends.dir}/libs/windows.x86_64
msvcr.dll.x86_64=${msvcr.dir.x86_64}/msvcr80.dll
On 5/15/07, Nathan Beyer <[EMAIL PROTECTED]> wrote:
> I've been running into the following problem with the msvcr71.dll
> that's copied from my windows/system32.
>
> File depends/libs/windows.x86/msvcr71.dll has incorrect md5 checksum.
Expected:
>
> 86f1895ae8c5e8b17d99ece768a70732
> found:
> ca2f560921b7b8be1cf555a5a18d54c3
>
> I thought perhaps it was just a problem on one of my servers, but I've
> run into this on multiple machines. What I've found is that there's a
> VS2003 service pack (SP1) that were installed on my servers when I
> recently installed VS2003, which seems to change the msvcr71.dll in at
> least a minor way; enough to change the md5 sum.
>
> Would anyone object to updating the build files to use this new
> checksum and changing the build instructions to use VS2003 SP1?
>
> Another option would be to check both hashes and allow if one is fine.
>
> -Nathan
>
--
Tony Wu
China Software Development Lab, IBM
