On Apr 1, 12:24 pm, Cactus <[email protected]> wrote: > On Apr 1, 11:55 am, "jason" <[email protected]> wrote: > > > The shared/dll build is not be correct ,as I think besides mpir.dll another > > "link library?" should be created ie mpir.something , this is just a matter > > of compiler flags, need someone with more windows knowledge than me... > > > Thanks > > Jason > > > ----- Original Message ----- > > From: "jason" <[email protected]> > > To: "mpir-devel" <[email protected]> > > Sent: Friday, April 01, 2011 11:14 AM > > Subject: [mpir-devel] Re: MSVC command line build > > > Hi > > > I've tweeked the command line build some more , now you hopefully can > > run it with a > > configure > > make > > make check > > make speed > > make tune > > make clean > > > configure on it's own should autodetect cpu type , set up yasm and > > msvc paths but you can override these settings with > > --enable-shared --enable-static --disable-shared --disable-static -- > > ABI64 --ABI32 and --cpu-* for each cpu type (same as linux/mingw64 > > now) > > The logic for finding a suitible compiler and yasm is probably not > > right , I dont know enough about how these things are usally installed > > on windows. > > It should work like this. > > if a compiler is in path and abi is not specified then use that > > if a compiler is in path and abi matches then use that > > if VS 10 exists and can be set up with the required abi then use that > > if VS 8 exists and can be set up with the required abi then use that > > give up > > > So we still need the logic for VS2005 and the express editions , who > > has a install of them for testing ? > > for finding yasm I use > > if yasm.exe or vsyasm.exe is in path use that > > if YASMPATH is set then use YASMPATH\yasm.exe or the vsyasm version > > if vsyasm.exe exists in the VS2010 vc/bin path then use that > > if vsyasm.exe exists in the VS2010 custom bin path then use that > > if yasm.exe exists in the VS2008 vc/bin path then use that > > give up > > > I suppose we could build yasm from the source shipped with MPIR (would > > need to ship a few generated files) > > > The flags chosen are probably not too hot , and there is no per-cpu > > optimizations. > > All the commands have to run in the same shell due to the way MSVC > > sets up paths. > > > not added any cpu paths for 32bit yet as I dont know how they are > > built , do they use yasm? , but nothing difficult here. > > > There are a few errors/warnings in the make still , these just get > > ignored for the mo > > The c++ lib is just included in mpir.lib or dll , this should be easy > > to fix > > > make check mpz/reuse fails to build , easy fix to do > > make check locale test fails to build , same type of fix we use for > > mingw64 etc > > make check doesn't stop on error yet as we need to see all the tests > > for the mo > > > try fails to build do to duplicate defs of the PITA divrem_preinv > > stuff , this is obsolete and we should replace this code rather than > > hack the build. > > > Have fun > > Jason > > > On Mar 31, 1:23 pm, Bill Hart <[email protected]> wrote: > > > Huh? Why on earth should a linear function cause a runtime stack > > > overflow? Do we allocate a pile of temporary memory or something? Are > > > we using TMP_SALLOC regardless of size or something? > > > > On 30 March 2011 20:49, jason <[email protected]> wrote: > > > > > This warning is a bit worring (and for linux) , although make check > > > > passes > > > > > mpn\generic\andn_n.c(77) : warning C4717: '__gmpn_andn_n' : recursive on > > > > all > > > > control paths, function will cause runtime stack overflow > > > > > this is for all logic and copy functions , although they are overridden > > > > by > > > > asm functions later > > > > > Also at the moment I have just put C and C++ into mpir.lib , do we want > > > > or > > > > need to have two separate libs? > > > > > Thanks > > > > Jason > > > > > ----- Original Message ----- From: "jason" <[email protected]> > > > > To: <[email protected]> > > > > Sent: Wednesday, March 30, 2011 8:15 PM > > > > Subject: Re: [mpir-devel] Re: MSVC command line build > > > > >> Hi > > > > >> I got the tests/mpz/reuse.c to compile by > > > > >> defining __STDC__ so that line 158 in tests/mpz/reuse.c uses the ## > > > >> token > > > >> concatcation version > > > > >> /* Really use `defined (__STDC__)' here; we want it to be true for Sun > > > >> C > > > >> */ > > > >> #if defined (__STDC__) || defined (__cplusplus) > > > >> #define FAIL(class,indx,op1,op2,op3) \ > > > >> do { \ > > > >> class##_funcs[indx] = 0; \ > > > >> dump (class##_func_names[indx], op1, op2, op3); \ > > > >> failures++; \ > > > >> } while (0) > > > >> #define FAIL2(fname,op1,op2,op3) \ > > > >> do { \ > > > >> dump (#fname, op1, op2, op3); \ > > > >> failures++; \ > > > >> } while (0) > > > >> #else > > > >> #define FAIL(class,indx,op1,op2,op3) \ > > > >> do { \ > > > >> class/**/_funcs[indx] = 0; \ > > > >> dump (class/**/_func_names[indx], op1, op2, op3); \ > > > >> failures++; \ > > > >> } while (0) > > > >> #define FAIL2(fname,op1,op2,op3) \ > > > >> do { \ > > > >> dump ("fname", op1, op2, op3); \ > > > >> failures++; \ > > > >> } while (0) > > > >> #endif > > > > >> or should we use a separate || defined(_MSVC) or whatnot? > > > > >> Thanks > > > >> Jason > > > > >> ----- Original Message ----- From: "jason" <[email protected]> > > > >> To: <[email protected]> > > > >> Sent: Sunday, March 20, 2011 11:47 PM > > > >> Subject: Re: [mpir-devel] Re: MSVC command line build > > > > >>> Cheers > > > > >>> make try speed tune are all done , and everything runs fine on my > > > >>> setup. > > > >>> The reason it was so easy is that all I had to do is compile and link > > > >>> , all > > > >>> the hard work has already been done by Brian for the GUI build. > > > > >>> Now to get it to set the paths for the other versions of MSVC , what > > > >>> about VS2005 ? do we know the paths ,and are the express editions the > > > >>> same ? > > > >>> could we call some sort of builtin windows search tool ? > > > > >>> As to choosing the mpn paths from the cpu type , instead of a python > > > >>> script to do it , I was thinking of a plain text file which just lists > > > >>> the > > > >>> cpu's and the paths and flags , and then the parsing can be done in > > > >>> the > > > >>> native script of the OS > > > > >>> Jason > > > > >>> ----- Original Message ----- From: "Cactus" <[email protected]> > > > >>> To: "mpir-devel" <[email protected]> > > > >>> Sent: Sunday, March 20, 2011 5:01 PM > > > >>> Subject: [mpir-devel] Re: MSVC command line build > > > > >>> On Mar 20, 4:41 pm, "jason" <[email protected]> wrote: > > > > >>>> ----- Original Message ----- > > > >>>> From: "Cactus" <[email protected]> > > > >>>> To: "mpir-devel" <[email protected]> > > > >>>> Sent: Sunday, March 20, 2011 2:11 PM > > > >>>> Subject: [mpir-devel] Re: MSVC command line build > > > > >>>> On Mar 20, 1:19 pm, "jason" <[email protected]> wrote: > > > >>>> > Also in the batch script , I've assumed that cl.exe and yasm.exe > > > >>>> > are > > > > >>>> > at > > > >>>> > some > > > >>>> > fixed location , we just need some code to find out where they > > > >>>> > really > > > >>>> > > are > > > >>>> > on > > > >>>> > the system or we could just assume they are already in PATH. > > > >>>> > The existing batch script which calls the project/solution files is > > > > >>>> > still > > > >>>> > needed if we want to automate testing of the GUI builds. > > > > >>>> > Jason > > > > >>>> > ----- Original Message ----- > > > >>>> > From: "jason" <[email protected]> > > > >>>> > To: <[email protected]> > > > >>>> > Sent: Sunday, March 20, 2011 1:12 PM > > > >>>> > Subject: Re: [mpir-devel] Re: MSVC command line build > > > > >>>> > >I haven't done the C++ stuff yet , but I can't see it being > > > > >>>> > > >difficult. > > > >>>> > > This should also backport to MPIR-2.3 , 2.2 and 2.1 if we want to > > > >>>> > > , > > > >>>> > > > > this > > > >>>> > > should be pretty trivial. > > > > >>>> > > Jason > > > > >>>> > > ----- Original Message ----- > > > >>>> > > From: "jason" <[email protected]> > > > >>>> > > To: <[email protected]> > > > >>>> > > Sent: Sunday, March 20, 2011 1:02 PM > > > >>>> > > Subject: Re: [mpir-devel] Re: MSVC command line build > > > > >>>> > >> Hi > > > > >>>> > >> In svn , in the directory win there is a MSVC command line build > > > > >>>> > >> >> that > > > >>>> > >> is > > > >>>> > >> independant of MSVC project/solution files. > > > >>>> > >> This should work on any MSVC , ie 2010 2008 2005? and the free > > > > > >>>> > >> versions > > > >>>> > >> I've done a > > > >>>> > >> make > > > >>>> > >> make_clean > > > >>>> > >> make_check > > > > >>>> > >> There are still a few minor bits to sort out , at the moment the > > > > >>>> > >> >> script > > > >>>> > >> is fixed to nehalem 64 bit build(see below) , a static lib , > > > > > >>>> > >> assumes > > > >>>> > >> stdint is availible , seems to create an endless %PATH% after a > > > > >>>> > >> >> number > > > >>>> > >> of > > > >>>> > >> runs , t-mpz_reuse wont build , t-locale wont build , and a few > > > > >>>> > >> >> other > > > >>>> > >> hacks , make try speed tune still to do , but mostly it's there > > > >>>> > >> and > > > >>>> > >> > >> it > > > >>>> > >> works > > > > >>>> > >> We need some code to select the mpn path dependant on cpu and > > > >>>> > >> this > > > >>>> > >> could > > > >>>> > >> be shared with the GUI builds and also Linux if we used python > > > > > >>>> > >> say(or > > > >>>> > >> C) > > > > >>>> > >> Jason > > > > >>>> > >> -- > > > >>>> > >> You received this message because you are subscribed to the > > > >>>> > >> Google > > > >>>> > >> Groups > > > >>>> > >> "mpir-devel" group. > > > >>>> > >> To post to this group, send email to > > > >>>> > >> [email protected]. > > > >>>> > >> To unsubscribe from this group, send email to > > > >>>> > >> [email protected]. > > > >>>> > >> For more options, visit this group at > > > >>>> > >>http://groups.google.com/group/mpir-devel?hl=en. > > > > >>>> > > -- > > > >>>> > > You received this message because you are subscribed to the > > > >>>> > > Google > > > >>>> > > Groups > > > >>>> > > "mpir-devel" group. > > > >>>> > > To post to this group, send email to [email protected]. > > > >>>> > > To unsubscribe from this group, send email to > > > >>>> > > [email protected]. > > > >>>> > > For more options, visit this group at > > > >>>> > >http://groups.google.com/group/mpir-devel?hl=en. > > > > >>>> Nice work Jason! > > > > >>>> The build will only work on Visual Studio 2008 because some of the > > > >>>> paths in your baatch files are specific to VS 2008 (e,g. > > > ... > > > read more » > > My internet connection, which has been down for 10 days, has only just > been restored so I am way behind with what has been happening on this. > > A DLL build should produce mpir.dll, mpir.lib, mpir.exp and > mpir.pdb. It is mainly a function of the linker and its switches to > set this up. Comparing the compiler/linker swirches in the lib and > dll *.vcxproj should give an idea of the switches that are needed. > > Brian
I've done some more tweeks , the configure options are now ABI=64 or ABI=32 and --cpu=nehalem etc I've split up the C and C++ librarys The shared library appears to build OK , we get an mpir.exe mpir.dll mpir.lib and a mpir.dll.manifest , but make check fail as the tests dont appear to link with it mpir\trunk\win>make check memory.c misc.c trace.c refmpn.c refmpz.c refmpq.c refmpf.c spinner.c getopt.c t-bswap.c misc.obj : error LNK2019: unresolved external symbol __gmp_rands referenced in f unction tests_rand_start misc.obj : error LNK2019: unresolved external symbol __gmp_rands_initialized ref erenced in function tests_rand_start misc.obj : error LNK2019: unresolved external symbol __gmp_allocate_func referen ced in function __gmp_allocate_func_aligned misc.obj : error LNK2019: unresolved external symbol __gmp_reallocate_func refer enced in function __gmp_allocate_or_reallocate misc.obj : error LNK2019: unresolved external symbol __gmpn_copyi referenced in function mpz_set_n refmpn.obj : error LNK2019: unresolved external symbol __gmp_modlimb_invert_tabl e referenced in function refmpn_divrem_hensel_qr_1 refmpn.obj : error LNK2019: unresolved external symbol __gmpn_mul_1 referenced i n function refmpn_mulmid_basecase refmpn.obj : error LNK2019: unresolved external symbol __gmpn_bases referenced i n function refmpn_get_str t-bswap.exe : fatal error LNK1120: 8 unresolved externals ..\..\tests\t-bswap.c FAILS Jason -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.
