On Wednesday 27 April 2011 09:51:32 Jason wrote: > On Wednesday 27 April 2011 07:26:18 Sisyphus wrote: > > ----- Original Message ----- > > From: "jason" > > > > >> What's the date on those compilers ? If they're more recent than my > > >> 20100414 > > >> and 20100306 I'll see if I can grab one or more of them to see if they > > >> work > > >> for me. > > > > > > yep yours were about a year old > > > > > > they were mingw-w64-1.0-bin_i686-mingw-20110207 and 20110408 > > > > Thanks for that, jason. > > > > These are both version 4.5.3. > > I haven't tried to build mpir with them. I'm sure it works, however, as > > both of these compilers (just like the 4.7.0 that I grabbed) are > > incapable of using anything my aging 4.6.0 built. > > > > Just posted to the mingw64 mailing list and found out the following: > > > > --quote-- > > > > > Win64-targeting builds from mingw-w64 up to 2010-04-27 didn't > > > follow MSVC x64 convention and did *not* prepend an undersocore > > > to the symbols: this is why you are seeing the incompatibilities > > > with the newer toolchains. > > > > > > All win64-targeting toolchains created after 2010-04-28, including > > > the sezero's gcc-4.4-based personal builds follow the MS convention. > > > > > > You should not be using those old toolchains. > > > > --end quote-- > > > > That's the secret then - just use a compiler later than 20100428. (If > > only I'd waited another fortnight before I downloaded that compiler :-) >
Our configure system can reject bad compilers , but for the test to work our assembler yasm would have to be built before it was configured , so the easiest way would be to test for the define __MINGW64__ and test on a define on the date when the compiler was built , if there is one , if not then I wont bother > Ah Ah , I'll put a note on our website about this > > > I guess mpir expects that the above mentioned convention is being > > followed - whereas the other libraries that I've been successfully > > building over the last year or so, make no such assumption and > > (presumably) allow the symbols to be prefixed correctly for the > > particular compiler. > > Yasm is compatible with MSVC , so it's that that is causing the mismatch , > if we used GAS , then it should work. I've got yasm to read the GAS code > (except for a FAT build!!!) and at some stage I was thinking of doing the > reverse (not that hard). > > The only other known problems for MinGW64 are > > ___chkstk has too many underscores which means that using a MinGW64 lib > with MSVC won't link > > make check fails for a C++ shared lib build , due to the lib's being in the > wrong place , almost certainly an autotools problem (MinGW32 had the same > problem until we upgraded autotools) > > make speed , try , or tune , all won't build due to autotools not setting > the correct include paths > > I wonder if the last two problems with autotools are to do with them > assuming *-pc-mingw32 rather than *-w64-mingw32 > > > Looks like I've got some work to do when I can get around to it .... > > gunna have to ditch that lovely ol' 4.6.0 compiler sooner or later > > anyway. > > > > Cheers, > > Rob ------------------------------------------------------------------------------ WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
