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. Bill. On 4 October 2012 00:13, Bill Hart <goodwillh...@googlemail.com> wrote: > Well, I tried a generic C build on linux and make try works fine > there. So some other mechanism is providing the missing function on > linux. > > Bill. > > On 4 October 2012 00:09, Bill Hart <goodwillh...@googlemail.com> wrote: >> They are overwritten because mpn/x86w/p3/divrem_1.asm is a >> multifunction file. It provides: >> >> export ___gmpn_divrem_1c >> export ___gmpn_divrem_1 >> >> However, it is overwritten with mpn/generic/divrem_1.c which only >> provides the latter of these symbols. >> >> Clearly for generic C builds, some other mechanism provides >> mpn_divrem_1c, or else try simply doesn't work at all with generic C >> builds (which would be a bug, even for linux). >> >> Bill. >> >> On 4 October 2012 00:00, Brian Gladman <b...@gladman.plus.com> wrote: >>> -----Original Message----- From: Bill Hart >>> Sent: Wednesday, October 03, 2012 11:49 PM >>> >>> To: mpir-devel@googlegroups.com >>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >>> >>> Actually, I do have MSVC installed. >>> >>> The build works fine on my machine and the tests pass. >>> >>> Then it says the following: >>> >>> try.c >>> try.obj : error LNK2001: unresolved external symbol ___gmpn_mod_1c >>> try.obj : error LNK2001: unresolved external symbol ___gmpn_divrem_1c >>> try.exe : fatal error LNK1120: 2 unresolved externals >>> >>> I don't know what it is doing at this point. But this is surely >>> irrelevant to the library itself, which seems to have already passed >>> all its tests by this stage. >>> >>> ===================== >>> >>> No, its a problem because these symbols should be present in the library but >>> they are absent. >>> >>> This doesn't show up in the tests because these functions are not tested as >>> they are trivial variations of the functions which they shadow, for example: >>> >>> fun_1c: >>> jump to enter >>> fun_1: >>> carry = 0 >>> enter: >>> rest of code >>> .... >>> >>> However, they show up when an attempt is made to link to try because it >>> tests the versions that have a carry input. >>> >>> I am still of the view that my earlier analysis is correct. What I don't >>> know, however, is why the assembler routines are overwritten. >>> >>> >>> 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.
