The number of open tickets for the release has shrunk somewhat: https://github.com/wbhart/mpir/issues?milestone=1&state=open
I will now wait until the Windows people are completely happy with everything and all Windows testing is complete, then I will put up an alpha and we can begin testing on other platforms. I have recently made quite a few changes to format specifiers in test code, so I hope this is all still ok on Windows. If not, please let me know. I didn't fix this problem permanently, which I think will involve adding some new format specifiers to gmp_printf and using it instead of printf, since MSVC doesn't support the c99 format specifiers. But this can wait until the next release. Or perhaps there is a way to make recent MSVC accept C99 format specifiers for uintmax_t, intmax_t and size_t and a workaround for %ld vs %lld. Bill. On 2 April 2014 18:18, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > > On Wednesday, April 2, 2014 6:09:07 PM UTC+2, Jean-Pierre Flori wrote: >> >> >> >> On Wednesday, April 2, 2014 11:34:30 AM UTC+2, leif wrote: >>> >>> Jean-Pierre Flori wrote: >>> > On Wednesday, April 2, 2014 1:47:30 AM UTC+2, Bill Hart wrote: >>> > >>> > All the C tests pass now. Just checking the C++ ones. >>> > >>> > >>> > On 2 April 2014 00:49, Bill Hart <goodwi...@googlemail.com >>> > <javascript:>> wrote: >>> > >>> > Got it! >>> > >>> > /* __GMP_DECLSPEC supports Windows DLL versions of libmpir, >>> and >>> > is empty in >>> > all other circumstances. >>> >>> Just wonder how the correct declarations of the affected (called) >>> functions vanished. >>> >>> >>> > Great! >>> > >>> > By the way, this looks quite interesting: >>> > http://www.cygwin.com/ml/cygwin/2002-01/msg00236.html >>> > >>> > Maybe we could just get rid of the dllexport/import nightmare? at >>> least >>> > on Cygwin (and MinGW?). >>> >>> >>> Yes. Just install Youbetcha... B) >>> >> Ok, my bad, we just don't need the dllimport stuff anymore in gmp.h >> (outside gmp_within_gmp_within_gmp). >> So we can actually build both static and shared libs now with a single >> header! >> > In fact we could also ignore the dllexport stuff with the "new" > auto-export --export-all-symbols (which is the default) ld option, as long > as there is no dllexport at all (see > https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html > ). > That will surely export more symbols as before though. > And as, if I understood correctly, the dllexport thing is needed anyway > for msvc, that won't simplify things. > (Whereas getting rid of dllimport allows to build both static and shared > with forcing us and the user to use dark magic.) > -- 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/d/optout.
