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? 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? 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? Maybe with the right information, I can track down the problem and find a suitable workaround. Bill. On 3 October 2012 14:36, Brian Gladman <b...@gladman.plus.com> wrote: > -----Original Message----- From: Case Van Horsen > Sent: Wednesday, October 03, 2012 1:42 PM > > To: mpir-devel@googlegroups.com > Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress > > On Tue, Oct 2, 2012 at 1:36 AM, Brian Gladman <b...@gladman.plus.com> wrote: >> >> -----Original Message----- From: Case Van Horsen >> Sent: Tuesday, October 02, 2012 7:43 AM >> To: mpir-devel@googlegroups.com >> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress >> >> [snip] >> >> >> Interesting. If I use ABI=64, then "make" and "make check" succeed. >> >> If I use "configure.bat ABI=32 --cpu=pentium3", then "make" succeeds >> but I get the following error for "make check": >> >> 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 >> ERROR >> >> Any ideas where to look? > > I don't have an answer yet but I have a clue. At line 110 in make.bat, > the obj files created from several asm files are deleted and replaced > by their generic equivalents. If I remove mod_1 from that block, I fix > one of the error messages but also generate a warning somewhere else. > > Do you have any idea why those particular files are replaced? > > Could there be an issue with the generic replacements? > > ========================== > Hi Case > > That pins it down nicely. > > The command line build depends on my Visual Studio build generator to > produce the config.h files and, in particular, the HAVE_NATIVE_symbol > defines for any symbols that are defined in any assembler files used. But > the command line build is not able to handle files which define multiple > symbols (I don't remember why) so any that are known to (or might) do so are > deleted and replaced by their generic equivalents. > > However my build system is more sophisticated and builds a symbol table for > all the assembler files used and generates HAVE_NATIVE_symbol defines for > all the symbols found. > > What this means is that any symbols that I pick up from files with more than > one symbol are expected to be available in the build. But they won't be in > the command line build because the files in question have been replaced by > generic files that don't define these symbols. > > Sadly knowing what is wrong and solving it are two different things. There > are several options. > > Firstly, we could try to modify the command line build to handle files with > multiple symbols but Jason would need to remind us what the problem is (Or > we need to find it). > > Second, we can split off a version of my build generator and modify it to > avoid generating HAVE_NATIVE_symbol defines for files with multiple symbols. > > Third we can just remove the secondary symbols from all files that define > them. This will have a small impact on performance but certainly not a > significant one. I don't think this would matter much on win32 but it would > be a pity to reduce the performance of the Visual Studio x64 build in this > way (I think some x64 files may have the same problem). > > Perhaps Jason can advise us on the best approach (I am not sure if he is > listening at the moment though). > > A more interesting option (for the future) is to use my build generator to > build the command line build files. > > > 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.
