On Wed, Oct 3, 2012 at 7:49 AM, 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). Just to clarify, I only use the command line tools for convenience to build an old version of gmpy. All builds for gmpy2 require MPFR and MPC so I now use the full Visual Studio builds. If fixing the command line tools becomes, I don't really need them. > > 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.
