Well, the problem is surely between lines 109 and 122 of make.bat. I don't have MSVC installed, so it's hard for me to test this.
It looks like the scheme is just to compile all the generic C files, then assemble all the asm files over the top of that, rewriting any generic object files. But then asm files that contain more than one symbol screw things up. So some of the generic object files have to be deleted as there are two of them (and with different names most likely) for each of the multi-function asm files. This strategy should work, obviously. But apparently it doesn't. I was a bit worried that there was mention of double underscore versus single underscore. Case, is there any way to check which object files you have after attempting a make, and which symbols they actually contain? 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.
