On Apr 28, 10:09 am, Jason <ja...@njkfrudils.plus.com> wrote:
> On Thursday 28 April 2011 09:04:01 Cactus wrote:
>
>
>
>
>
> > On Apr 28, 8:24 am, Cactus <rieman...@gmail.com> wrote:
> > > On Apr 28, 3:37 am, Jason <ja...@njkfrudils.plus.com> wrote:
> > > > On Thursday 28 April 2011 01:29:01 Jason wrote:
> > > > > On Thursday 28 April 2011 00:16:57 Jason wrote:
> > > > > > On Thursday 28 April 2011 00:12:14 Jason wrote:
> > > > > > > Hi
>
> > > > > > > I removed longlong.h from the distro , it is now constructed by
> > > > > > > configure (that was dead easy , used the same bit of code as that
> > > > > > > does gmp-mparam.h , although later on we integrate it with the
> > > > > > > mpn functions and gmp-impl.h) There is just a few ifdef to put
> > > > > > > back in there proper place (ie non-gnu asm code etc) , and the
> > > > > > > windows header will have cope with Mingw and MSVC(easy)
>
> > > > > > > Jason
>
> > > > > > I'll be removing the -DNO_ASM option , it serves no purpose now ,
> > > > > > it's only function what to stop the old longlong.h including asm
> > > > > > code in a generic C build.When you select a generic C build now
> > > > > > the standard path selection will of course not select any asm
> > > > > > code.
>
> > > > > > Jason
>
> > > > > I've put all the proper ifdef's back and done the 64bit windows
> > > > > header and the construction of longlong.h on the MSVC cl build
>
> > > > > The MSVC build projects will need to construct longlong.h via
> > > > > concatcation of longlong_pre.h arch_specific_longlong.h
> > > > > longlong_post.h
>
> > > > > see the longlong bit in win/make.bat
>
> > > > > I have also removed for some arch's some support for gcc version 1 :)
>
> > > > > We can also remove all this stuff
> > > > > HAVE HOST _CPU_x86 powerpc etc
> > > > > as this can now be taken care off with our standard path selection ,
> > > > > although there our a few files which will need some editing first.
>
> > > > > Jason
>
> > > > One possible problem is that longlong.h is now a built file rather than
> > > > a source file so if you build out of the tree , longlong.h is in a
> > > > different directory , this doesn't affect us , but some programs may
> > > > rely on it , from mpfr however
>
> > > > Building MPFR with internal GMP header files
> > > > ============================================
>
> > > > MPFR built with internal GMP header files is a bit faster, so you may
> > > > want to build it with them. Just do this in step 1:
>
> > > > ./configure --with-gmp-build=GMPBUILD
>
> > > > where GMPBUILD is the GMP build directory. The needed header files are:
> > > > gmp-impl.h, longlong.h and all the necessary headers to use them.
>
> > > > As gmp-impl.h and longlong.h are only in the GMP source directory,
> > > > you first need to copy these files to the build directory if it is
> > > > different (there may be other workarounds, such as setting $CPPFLAGS
> > > > to search the GMP source directory).
>
> > > > So we are now in the "right" place , and there nothing to say that
> > > > gmp-impl.h may also become a built file much like gmp.h
>
> > > > I could make the --enable-gmpcompat option also copy it to the source
> > > > dir ?
>
> > > > Jason
>
> > > I have a problem with the build now.
>
> > > The MSVC compiler first looks for header files in the same directory
> > > as a source code file and then, if this fails, in any specified header
> > > directories.
>
> > > As a result all the source code files in 'mpir\mpn\generic\' now pick
> > > up the empty longlong.h file in this directory and not the one in 'mpir
> > > \' as intended.
>
> > > The solution id either to rename the longlong.h architecture files to
> > > longlong.inc (or anything other than longlong.h) or change the C
> > > source code files to add a directory path to the longlong.h include
> > > line in each of them.
>
> > > I imagine that the former solution is the easiest - should I do this?
>
> > > Brian
>
> > I suggest that we use the names:
>
> > longlong_pre.h
> > longlong_inc.h
> > longlong_post.h
>
> > I now have a build based on this change but I have not committed it
> > yet in case this is a problem for other builds.
>
> > Brian
>
> Yep , that great , commit it and I can change the autotools bits.
>
> I'm still having problems with FAT builds and the incestuous files preinv
> divrem_1 mod_1 and the mess that configure uses to build them :(
>
> Thanks
> Jason
Ok, I have now done (I hope) all the file name changes and the MSVC
build chaange.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-devel@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.
