On 05/08/2013 10:40, Jean-Pierre Flori wrote:
> 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.
You are making good progress! It will be nice to have builds with the
32 and 64 bit versions of both mingw and cygwin.
> 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.
Visual Studio can cope with mixed line endings but I am much less
certain about YASM on Windows as I recall having problems with LF
endings in the *.asm files. I may be wrong but I think we ended up with
LF endings everywhere except for the dedicated Windows files in x86w,
x86_64w and the Windows build directories (basically all the stuff that
I manage for the Visual Studio/YASM builds).
> 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.
As you say, the commented PROLOGUE stuff in the files in the
x86w/x86_64w directories is there to support building with
mingw/mingw64. I don't use these lines anywhere in the Visual Studio
build as I scan the files for exported symbols using a different approach.
Brian
--
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.
