I actually don't think I had problems on MinGW64 either. But I'd have to check to be sure.
The problem with using the other kind of magic is old versions of Cygwin which don't support it. I don't know if these exist or not. And whether they build MPIR anyway is entirely another consideration. I think we definitely should look at providing the ability to do both static and shared builds for Windows at the next release. If I'm understanding correctly, that means we get rid of one kind of magic and replace it with another. The user doesn't have to change anything? Bill. On 7 April 2014 16:20, Jean-Pierre Flori <jpfl...@gmail.com> wrote: > > > On Wednesday, April 2, 2014 6:18:40 PM UTC+2, Jean-Pierre Flori 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.) >> > Ok, I think I mostly got the dllimport/segfault issue on Windows64. > > It seems one has to use the yasm export directive (one may pass -DDLL to > yasm to define DLL and trigger its use) or gcc somehow screws up and you > end up with a wrong function call in your binary. > What is strange is that: > * if you use the dllimport magic, everything is fine without the export > directive. > * with the export directive you don't need the dllimport magic. > And: > * everything is fine on Cygwin32 without both of them but there gas is > used (for most files at least). > > Any thought about that? > -- 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.
