trunk now builds under mingw64 (C only) (ie
./configure --build=none-pc-mingw32)
It passes make check (except for t-locale , which fails on MSVC as well)
I've tested vs2008 , and all is OK , I can't imagine any problems with
vs2010
I'll change the t-locale test so that it is skipped for WIN64
There are some cosmetic changes that need to be done.
config.guess reports x86_64-pc-mingw32 , ie it doesn't detect the cpu , the
pc bit should be w64 and mingw32 should be mingw64 , and upgrade to GNU
config may fix some of these.
make speed,tune fails
I've only tried a static lib so far , not tried make try , etc......
Jason
----- Original Message -----
From: "jason" <ja...@njkfrudils.plus.com>
To: "mpir-devel" <mpir-devel@googlegroups.com>
Sent: Saturday, August 14, 2010 12:03 PM
Subject: [mpir-devel] Re: MPIR 2.2
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.
--
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.
