On Aug 28, 9:59 am, "jason" <ja...@njkfrudils.plus.com> wrote: > Hi > > I think I know why the mingw64 dll builds fail , for multiple functions files > ie aors_err2_n.asm , in the MSVC build yasm emits both functions in a single > "unit" , whereas under mingw64 we create two links add and sub versions (like > we do for unix) , and also yasm still emits both functions , so we end up > with two copys. The same must happen in the static build , but it doesn't > seem to matter? > I was planning to get rid of such complications ( or rather move them to > development machines only , much like autotools generates Makefile.in) , a > small script should easily take of it.
I wwould be very happy to make several changes that are related to this issue, all of which would make all the Windows builds much easier: 1. All files emit only one routine and only one symbol (this would expand the source for some 'carry in' and 'no carry in' variants); 2. A strict equality between C and assembler file names and the symbols they emit (ignoring the prefix); 3. A new extension (i.e not c, cc, as, asm, ..) for files that are not compiled directly but are included in other files. I don't think it matters issuing HAVE_NATIVE defines for all assembler symbols even if they aare complete C replacements so we can (I think) ignore this. This would allow a major simplification in the Windows builds since it would then be possible to generate most of the build files automatically for any Windows build tools. > For the t-locale test , is there no way that MSVC will pass it ? , if so I'll > ifdef it out , with ! _MSC_VER , because under mingw I think I can get it to > pass , it looks like the redefinition of localenv just needs a DECLSPEC I haven't tried a DECLSPEC - I see if it works. Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.