-----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.
