The whole business of defining LONG_LONG_LIMB is a bad idea. What I mean is that good programming is to hide infomation , once we define mp_limb_t (as whatever) in mpir.h , then the rest of mpir's code , and any programs built on libmpir should not need to know that it is a long or long long or whatever. If they want the size , use GMP_LIMB_BITS. There are only two places where this may be a problem. Constants can need LL instead of L , but proper use of CNST_LIMB(x) macro covers this printf("%ld",(mp_limb_t)x); need to use the proper gmp_printf
We can still define LONG_LONG_LIMB (after the fact) for all those badly writen librarys out there that depend on it , but I think internally we should not depend on it. I think the only place a long long limb is used in anger , is Win64 , or the only modern ABI. Anyway , to get mingw64 working , I will stick to how we do it for the moment. Jason On Aug 14, 11:02 am, Jason <ja...@njkfrudils.plus.com> wrote: > On Saturday 14 August 2010 10:03:09 Cactus wrote: > > > > > > > On Aug 14, 9:00 am, Cactus <rieman...@gmail.com> wrote: > > > On Aug 14, 4:02 am, "jason" <ja...@njkfrudils.plus.com> wrote: > > > > Hi Brian > > > > > I notice that for win64 you have a scipt gen_mpir_h.bat which define's > > > > LONG_LONG_LIMB 1 > > > > > Is there any reason you did it this way , rather than at somewhere > > > > before line194 in gmp-h.in > > > > #ifdef _WIN64 > > > > #define _LONG_LONG_LIMB 1 > > > > #endif > > > > > because for the mingw64 I need to set it anyway. > > > > There are several reasons for this, one being a desire to be able to > > > define what I need on Windows without changing files in the MPIR > > > distribution. This is partly historical and comes from my GMP build > > > at a time when I could not expect TG to allow any Windows changes into > > > gmp_h.in. > > > > The second, more important, reason is that this aligns with the > > > intended pre-processing of gmp-h.in, which includes @symbol@ values > > > that are intended for substitution when gmp-h.in is used to build to > > > build gmp.h or mpir.h. I have to either remove or substitute all > > > these @symbol@ values so it is natural to do the definitions during > > > this process (whiich I assume parallels what happens in the Unix/Linux > > > builds). > > pretty much > > > > But it turns out that the are significant benefits for the Visual > > > Studio IDE, that can be much faster when such conditionals are not > > > present because its intellisense database, which enables code and > > > symbol browsing in the IDE, background compiles both code paths for > > > conditionals in order to create its database (this is not quite what > > > it does but it would be hard to explain the full story of how it > > > avoids the combinatorial explosion in code paths). > > > > But if you need it in gmp-h.in, I think my script will still work > > > provided all the associated @symbol@ elements in gmp-h.in are removed. > > > > Brian > > There is another place it is used. > When running configure (This is before we know how to fill all these > @symbols@) > , the configure script compiles a short c prog to test the size of a mp_limb_t > ie output from configure (linux 64bit) > checking for assembler byte directive... .byte > checking how to define a 32-bit word... .long > checking if .align assembly directive is logarithmic... no > checking if the .align directive accepts an 0x90 fill in .text... yes > checking size of unsigned short... 2 > checking size of unsigned... 4 > checking size of unsigned long... 8 > checking size of mp_limb_t... 8 ####################### > creating config.m4 > configure: creating ./config.status > config.status: creating Makefile > config.status: creating mpf/Makefile > > I not sure it is strictly necessary , but for the mo we need it . As I rip > autotools to bits , it may not survive. > > Todo this is sets the define __GMP_WITHIN_CONFIGURE and just includes gmp-h.in > > So I can guard it with the above define , which is not set by MSVC . Although > I > may need to set it again for the build , I'll have to try it to find out. > > > > > In fact, provided your definition occurs before line 60 (I think), all > > my script will do is to add a redundant define since it is guarded. > > > If you wish to add it later, all it needs is a guard to avoid multiple > > definitions. > > > But I assume that the Unix/Linux builds have to process gmp-h.in to > > produce mpir.h including the relevant substitutions --- shouldn't the > > mingw64 build do the same? > > > Brian- Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@googlegroups.com. To unsubscribe from this group, send email to mpir-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/mpir-devel?hl=en.