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
--
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.
