On Thu, Oct 4, 2012 at 8:08 AM, Case Van Horsen <cas...@gmail.com> wrote: > 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. Just curious - why do you both #undef and #define to 0? Shouldn't #undef be sufficient?
Case >> > 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.
