I've now fixed my trunk and performed basic testing (building and running the testsuite, sahred and static) on different flavours of MinGW64 (both 32 and 64 bits) and Cygwin (both 32 and 64 bits) and everything seems fine.
I've also (tried to) put back vanilla Yasm (1.2.0) sources, and added the possibility to use a system wide one. The only modifications to these sources are now done at configure time (use updated config.(guess|sub) and a stub configure.gnu to discard superfluous configure options). I've used "autoreconf -fiv --disable-recursive" to update the build system at the toplevel so that yasm subdirectory was not updated. I'm not quite convinced that shipping the file generated by autoreconf (or equivalent commands) in the git trunk is such a good idea. It seems to me that most projects only ship the input to autotools there and generate the build system at release time (and for testing/devel on one's computer of course!). I've not struggled enough with git to manage to convince it to keep the CRLF line endings in the Yasm files having some (mostly in the VS build projects). So these have been automatically converted to LF at commit time. This should not be a problem as Yasm is not built with VS anyway. Note that an old commit ensured that the x86*w files also had CRLF line endings. This was still the case in the 2.6.0 tarball (and gave me troubles with MinGW at configure time) but was changed later (after the 2.6.0 release I'd say) in Bill's git trunk. I have not tested anything with VS so I don't know if having assembly files with LF line endings is a problem for the VS projects. Whatsoever, if VS requires CRLF line endings, then some magic translation will have to be performed at configure time so that both VS and MinGW are happy. The final obscure point is about the GLOBAL_FUNC/PROLOGUE declarations in the comment parts of the x86_64w assembly code. There are some commits mentionning adding the GLOBAL_FUNC piece and then converting it to PROLOGUE and then removing duplicate PROLOGUE declarations (always in the comments, so without real influence). The strange thing is that when the GLOBAL_FUNC was introduced, it dropped the mpn_ prefix in the function names and that prevented the functions to be correctly detected by the configure scripts and so the correct HAVE_NATIVE_* to be defined. In particular, that could lead to a problem already mentioned here: mpn_addmul_2 being defined twice on MinGW because redc_2 found that HAVE_NATIVE_mpn_addmul_2 != 1 whereas the function was already provided. >From what I understood, this GLOBAL_FUNC/PROLOGUE in the comments trick was only there to help the configure scripts on MinGW, so I've transformed it to produce correct results there (and on Cygwin 64). I did not find any trace of it being used for VS, except for the g2y.py script which, if I understood correctly, is used to translate GAS asm to Yasm asm, and so is not used at build time. If the VS project actually depend on these PROLOGUE declarations (within the top-level comments), then I might have broken the VS projects. Best, JP On Wednesday, July 31, 2013 11:21:59 AM UTC+2, Bill Hart wrote: > > Wow. That's really awesome! > > Bill. > > > On 31 July 2013 09:54, Jean-Pierre Flori <jpf...@gmail.com > <javascript:>>wrote: > >> Hi all, >> >> I've upped a version of MPIR seemingly passing all its tests on Cygwin64 >> at https://github.com/jpflori/mpir.git (including the fix for t-scan >> from https://groups.google.com/forum/?hl=en#!topic/mpir-devel/oLk3gMULxu0). >> Note that I've not included the complete fixes suggested at >> http://cygwin.com/ml/cygwin/2013-06/msg00580.html to remove the now >> obsolete hacks to shorten configure time. >> I've dos2unix'ed some files though it does not seem to appear in any of >> the commits I pushed... >> Finally some of the fixes I included do not make any difference between >> Cygwin32 and Cygwin64, this actually broke MPIR on Cygwin32; I'm working on >> it. >> >> At some point I'll also try to make the build of yasm optional, and >> correct when cross compiling (see >> https://groups.google.com/forum/?hl=en#!topic/mpir-devel/oLk3gMULxu ). >> I'll also give a shot to the static/shared limitation a shot. >> >> Best, >> JP >> > > -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to mpir-devel+unsubscr...@googlegroups.com. To post to this group, send email to mpir-devel@googlegroups.com. Visit this group at http://groups.google.com/group/mpir-devel. For more options, visit https://groups.google.com/groups/opt_out.
