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. Bill. On 3 October 2012 22:40, Case Van Horsen <cas...@gmail.com> wrote: > On Wed, Oct 3, 2012 at 2:34 PM, Bill Hart <goodwillh...@googlemail.com> wrote: >> Where is the file make.bat located? > > In the "win" directory. I'm testing by doing the following: > > cd mpir\win > configure ABI=32 --cpu=pentium3 > make > make check > > >> >> Bill. >> >> On 3 October 2012 15:49, Brian Gladman <b...@gladman.plus.com> wrote: >>> -----Original Message----- From: Bill Hart >>> Sent: Wednesday, October 03, 2012 3:25 PM >>> >>> To: mpir-devel@googlegroups.com >>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >>> >>> I definitely don't think option 3 will work. We need the defines for >>> the MinGW32 build, and having just gotten that to work, I definitely >>> don't want to risk breaking it. >>> >>> Option 1 seems best to me (being ignorant of the aforementioned >>> problems with this approach). Failing that, we can try 2. >>> >>> Brian, there must be two stages to this. The first must be a stage >>> which looks through the assembly files for GLOBAL_FUNC macros and >>> outputs the relevant HAVE_NATIVEs. I assume this is your Python build >>> generator? >>> >>> ========================== >>> Yes, my build generator collects a list of the assembler files in the x86w >>> and x86_64w directory and their sub-directories and then scans these files >>> for the symbol definitions (looking for the various procedure MACROs such as >>> LEAF_PROC, FRAME_PROC etc.). These are then used to build the a symbol table >>> for each sub-directory. >>> >>> The symbols defined by the files in each directory are then used to build >>> the cfg.h files in each directory and these are then used to build the >>> HAVE_NATIVE_symbol defines. >>> ========================== >>> >>> >>> Is it this build generator which does the deletion and replacement >>> with generic files? If so, does it replace with *both* generic files, >>> one for each symbol to be defined? >>> >>> ========================== >>> No, this is done in make.bat, the command line batch file. >>> ========================== >>> >>> >>> What is the other part of the process? I mean the part that Jason says >>> has a problem with multiply defined symbols. I assume this is the >>> command line build system itself? Is that make.bat or some other file >>> where this happens? >>> >>> ========================== >>> This is an issue with make.bat (bear in mind that I know little or nothing >>> about this since it is Jason's creation that is being maintained by Case at >>> the moment). >>> >>> As I said earlier, I remember Jason having issues with files that define >>> multiple symbols but I don't recall what the problem was. >>> ========================== >>> >>> >>> Maybe with the right information, I can track down the problem and >>> find a suitable workaround. >>> >>> ========================== >>> A lot of the multiple symbols are of the form: >>> >>> carry_entry: >>> go to entry >>> main_entry: >>> set carry = 0 >>> entry: >>> code ... >>> >>> Another solution, at the coast of more binary code, is to duplicate all of >>> these files and define a single symbol in each file. >>> ========================== >>> >>> >>> 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.
