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.

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.

Reply via email to