By a process of elimination, this problem occurs on both core2 and
k10, so it must be one of the following:
U cpuid.c
U mpn/x86_64/k8/k10/karasub.asm
U mpn/x86_64/core2/karasub.asm
U mpn/asm-defs.m4
U config.in
U configure.in
U gmp-h.in
U acinclude.m4
U Makefile.am
But we can exclude acinclude.m4 as this was the test for a broken gcc
4.3.2, which is not relevant.
We can exclude cpuid.c as this is cpu detection for sandybridge and atom.
We can exclude the karasub.asm files as these just define new versions
of karatsuba.
That leaves:
U mpn/asm-defs.m4
U config.in
U configure.in
U gmp-h.in
U Makefile.am
Looking through, this change in configure.in looks suspicious:
- sed -n 's/[^G]*GLOBAL_FUNC[:space:]*\(.*\)/\1/p' $tmp_file
+ sed -n 's/^;[ ]*PROLOGUE(\([^,]*\).*)/\1/p' $tmp_file ;
It looks like all the yasm files use GLOBAL_FUNC and all the gas files
use PROLOGUE, so I don't completely understand this change. It might
be correct.
Most of the other files that have changed have changes to something
relating to redc_2, which does show up in the error message. But it
can't explain both problems.
Anyhow, going back to the original error message, there is a file
mpn/generic/preinv_divrem_1.c which defines a symbol
mpn_preinv_divrem_1, which is guarded with:
#if USE_PREINV_DIVREM_1
But then we have:
[wbhart@eno mpir-exp]$ grep GLOBAL_FUNC mpn/divrem_euclidean_qr_1.as
GLOBAL_FUNC mpn_preinv_divrem_1
GLOBAL_FUNC mpn_divrem_euclidean_qr_1
In mpn/generic/redc_2.c we have:
#ifndef HAVE_NATIVE_mpn_addmul_2
mp_limb_t
mpn_addmul_2 (mp_ptr rp, mp_srcptr up, mp_size_t n, mp_srcptr vp)
{
rp[n] = mpn_addmul_1 (rp, up, n, vp[0]);
return mpn_addmul_1 (rp + 1, up, n, vp[1]);
}
#endif
But then we have:
[wbhart@eno mpir-exp]$ grep GLOBAL_FUNC mpn/addmul_2.as
GLOBAL_FUNC mpn_addmul_2
So it looks to me like this fix in configure.in is correct, but it
causes two other bugs (symbols defined when they shouldn't be) to show
up.
So we need to figure out how to set USE_PREINV_DIVREM_1 to 0 when it
is supposed to be and to define HAVE_NATIVE_mpn_addmul_2 when it is
supposed to be.
This is where we need Jason to jump in and say he knows how to fix the
problem....
Bill.
On 28 July 2012 01:05, Bill Hart <goodwillh...@googlemail.com> wrote:
> Nope, autoconf and automake didn't do anything.
>
> The problem must lie in one of the following files:
>
> U Makefile.in
> U cpuid.c
> U mpn/x86_64w/fat/fat_entry.asm
> U mpn/powerpc64/gmp-mparam.h
> U mpn/x86_64/k8/karasub.asm
> U mpn/x86_64/k8/k10/karasub.asm
> U mpn/x86_64/bobcat/karasub.asm
> A mpn/x86_64/bobcat/redc_1.as
> U mpn/x86_64/sandybridge/karasub.asm
> A mpn/x86_64/sandybridge/redc_1.as
> U mpn/x86_64/atom/karasub.asm
> U mpn/x86_64/netburst/karasub.asm
> U mpn/x86_64/nehalem/karasub.asm
> U mpn/x86_64/core2/karasub.asm
> U mpn/asm-defs.m4
> U devel/setversion
> U doc/mpir.info-1
> U doc/mpir.texi
> U doc/mpir.info-2
> U doc/mpir.info
> U doc/stamp-vti
> U doc/version.texi
> U config.in
> U NEWS
> U configure.in
> U configure
> U tests/mpn/t-addadd_n.c
> U tests/mpn/t-addsub_n.c
> U tests/mpn/t-subadd_n.c
> U tests/devel/try.c
> U gmp-h.in
> U acinclude.m4
> U Makefile.am
> U .
>
> In fact, the issue seems to occur at the final linking stage, not when
> linking the mpn archive.
>
> Bill.
>
> On 28 July 2012 00:55, Bill Hart <goodwillh...@googlemail.com> wrote:
>> In fact, the problem already occurs in the mpir-exp branch. So this
>> must be the result of a merge conflict from trunk to mpir-exp.
>>
>> Bill.
>>
>> On 28 July 2012 00:50, Bill Hart <goodwillh...@googlemail.com> wrote:
>>> Unfortunately the merge doesn't seem to have gone without issue. When
>>> I try to build on linux now it configures ok, but I get the following
>>> when it tries to link the mpn archive during the build:
>>>
>>> mpn/.libs/preinv_divrem_1.o: In function `__gmpn_preinv_divrem_1':
>>> preinv_divrem_1.c:(.text+0x0): multiple definition of
>>> `__gmpn_preinv_divrem_1'
>>> mpn/.libs/divrem_euclidean_qr_1.o:divrem_euclidean_qr_1.as:(.text+0x0):
>>> first defined here
>>> mpn/.libs/addmul_2.o: In function `mpn_addmul_2':
>>> addmul_2.as:(.text+0x0): multiple definition of `__gmpn_addmul_2'
>>> mpn/.libs/redc_2.o:redc_2.c:(.text+0x0): first defined here
>>> collect2: ld returned 1 exit status
>>> make[2]: *** [libmpir.la] Error 1
>>> make[2]: Leaving directory `/home/wbhart/mpir-new'
>>> make[1]: *** [all-recursive] Error 1
>>> make[1]: Leaving directory `/home/wbhart/mpir-new'
>>> make: *** [all] Error 2
>>>
>>> There's no obvious reason for this, other than non-commuting patches
>>> which have maybe screwed up a makefile or something. I'll try running
>>> autoconf and automake again and see if it sorts itself out.
>>>
>>> Bill.
>>>
>>> On 27 July 2012 14:34, Brian Gladman <b...@gladman.plus.com> wrote:
>>>> -----Original Message----- From: Brian Gladman
>>>> Sent: Friday, July 27, 2012 11:39 AM
>>>>
>>>> To: mpir-devel@googlegroups.com
>>>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress
>>>>
>>>> -----Original Message----- From: Bill Hart
>>>> Sent: Thursday, July 26, 2012 10:40 PM
>>>> To: mpir-devel@googlegroups.com
>>>> Subject: Re: [mpir-devel] Re: MPIR 2.6 release progress
>>>>
>>>> Doing things manually risks overwriting changes that have been made in
>>>> trunk and may be error prone. We'd also lose the original commit data.
>>>>
>>>> I don't like the idea of doing it without a proper merge.
>>>>
>>>> =================================
>>>> I have done the merge from trunk into the mpir-exp branch and all is well
>>>> on
>>>> Windows.
>>>>
>>>> Most of the stuff that SVN reported was spurious as far as I can see.
>>>>
>>>> But we now have a potentially nasty problem - in testing the merge from
>>>> MPIR-EXP into trunk, I get the message:
>>>>
>>>> Error: Querying mergeinfo requires version 3 of the FSFS filesystem schema;
>>>> filesystem
>>>> Error: '/home/mpir/svn_repos/mpir/db' uses only version 2
>>>>
>>>> On googling, I find that solving this problem seems to require a Subversion
>>>> upgrade on the server followed by a repository dump and reload.
>>>>
>>>> If we cannot organise this upgrade (which I assume won't be easy or quick
>>>> since there are likely to be many SVN users impacted by it), we will have
>>>> to
>>>> revert to adding the changes in MPIR-EXP to the trunk manually as I
>>>> suggested yesterday.
>>>>
>>>> What is your view on this Bill?
>>>>
>>>> ====================================
>>>> I have now figured out how to the merge without mergeinfo and I have merged
>>>> the mpir-exp branch into the trunk.
>>>>
>>>> The Windows Visual Studio builds are working so I would much appreciate it
>>>> if Case can look at the Windows command line build and Bill can look at the
>>>> *nix builds to see if anything needs doing.
>>>>
>>>>
>>>> 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.
