> The 1.0.0a release will not complete the build because configure > does not copy (several?) files to where they should be. One example > is "md2test.c". When make gets there, it is an empty file, and ld > produces an error. I can say 100% sure that the > 1.0.0-STABLE-20100331 snapshot does not have this problem, but can't > pinpoint it after that. > ... > This is becoming a bad habit, but after some more testing, the above > problem only occurs when using MSYS+1.0.0a release. It does not occur > when using linux to crosscompile, or in any of the daily stable > snapshots available.
MSYS and md2test.c... In 1.0.0a, but not in snapshots... *If* you are unpacking tar-ball under MSYS, then it must be a "packeting" issue. The thing is that [unlike snapshot tar-balls] 1.0.0 tar-ball has a number of symbolic links, test/md2test.c included, and the question is how MSYS, which has no concept of symbolic links, handles them. I don't know, but it *can* cheat by copying the file symbolic link points to. But what if file wasn't unpacked yet? In either case you should be able to work around the problem by unpacking tar-ball on Unix, repacking it with with -h (follow sym-link) flag and *then* moving it to MSYS. I don't know why release tar-balls have sym-links, but not snapshots... Nor do I feel to be in position to do something about it. Check if above workaround works and if you want to pursue the issue further, I'd suggest to open another ticket. A. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
