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