On Thu, Oct 4, 2012 at 7:48 AM, Bill Hart <goodwillh...@googlemail.com> wrote: > I've gone through all the files and there are only the two extra > symbols defined in mulfunc asm files which aren't provided by generic > code. > > I also think we should be appending these #undefs on 64 bit as well. > The reason is that we are removing the assembly files irrespective of > ABI. > > So I think the following: > > if %ABI% == 32 (echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h) > if %ABI% == 32 (echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h) > > should be > > echo #undef HAVE_NATIVE_mpn_mod_1c >> ..\config.h > echo #undef HAVE_NATIVE_mpn_divrem_1c >> ..\config.h > echo #define HAVE_NATIVE_mpn_mod_1c 0 >> ..\config.h > echo #define HAVE_NATIVE_mpn_divrem_1c 0 >> ..\config.h > > I am pretty sure we also need: > > echo #undef USE_PREINV_DIVREM_1 >> ..\config.h > echo #define USE_PREINV_DIVREM_1 1 >> ..\config.h > > Case, do you want to try this out, and if it works on 32 and 64 bit > builds, we'll call this problem fixed for now? Of course a more robust > solution would grep the assembly files and see what symbols are > available, etc. > I'll try that tonight. Case > Bill. > > On 4 October 2012 13:41, Bill Hart <goodwillh...@googlemail.com> wrote: >> This should work, but we should actually be appending #undefs for all >> the extra symbols in those files that get deleted (not for the ones >> that get replaced by generics of course). >> >> This probably means going through each directory for each arch, >> looking at the .asm files that are listed in make.bat (which get >> deleted) and adding #undefs for all the extra symbols. >> >> Bill. >> >> On 4 October 2012 04:07, Case Van Horsen <cas...@gmail.com> wrote: >>> On Wed, Oct 3, 2012 at 4:27 PM, Bill Hart <goodwillh...@googlemail.com> >>> wrote: >>>> Ah, I see. I'm slowly catching up. >>>> >>>> Perhaps the problem is that the .asm files don't all provide the same >>>> symbols. Some may provide one of the symbols, others both. >>>> >>>> The general configure yoga in the *nix side of things culls all the >>>> symbols to figure out which HAVE_NATIVE's to set probably. Because >>>> this is hard to do on Windows, the complication is "avoided" by using >>>> the generic files. >>>> >>>> I think the solution is to simply have make.bat purge the >>>> HAVE_NATIVE_DIVREM_1c from the config.h file. This should always work. >>>> In fact it is probably sufficient to simply append #undef >>>> HAVE_NATIVE_DIVREM_1c and #define HAVE_NATIVE_DIVREM_1c 0 to the file. >>>> >>> >>> You got it! I have attached a new make.bat file that appends the >>> appropriate #undef's to the end of config.h. "make check" passes for a >>> 64-bit/K8 build and a 32-bit/pentium3 build. >>> >>> Case >>> >>>> Bill. >>>> >>>> On 4 October 2012 00:22, Brian Gladman <b...@gladman.plus.com> wrote: >>>>> -----Original Message----- From: Bill Hart >>>>> Sent: Thursday, October 04, 2012 12:19 AM >>>>> >>>>> To: mpir-devel@googlegroups.com >>>>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >>>>> >>>>> In config.h which it says is generated by gen_config_h.bat, it has: >>>>> >>>>> #define HAVE_NATIVE_mpn_divrem_1c 1 >>>>> >>>>> This is why it is expecting to find that symbol. >>>>> >>>>> Because gen_config_h.bat is a *** Visual Studio build file *** that Jason >>>>> 'borrowed'. >>>>> >>>>> And the Visual Studio build does provide this symbol. >>>>> >>>>> >>>>> 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. >>>>> >>>> >>>> -- >>>> 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. >>>> >>> >>> -- >>> 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. >>> > > -- > 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. >
-- 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.
