Thanks. I'll look into this and see if I can't spot the problem. Bill.
2009/1/19 Case Vanhorsen <cas...@gmail.com>: > > On 1/19/09, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> Hi Case, >> >> can you run ./config.guess for us on your machine (it is in the main >> directory of the source tree for MPIR). You may need to set >> permissions first by doing chmod 755 config.guess > > $ ./config.guess > core2-pc-mingw32 > >> You're right. It isn't fully figuring out that it needs to be doing 32 >> bit assembly on this machine. Probably we need to recognise that it is >> mingw and force it to use ABI=32 throughout. >> >> Bill. >> >> 2009/1/19 Case Vanhorsen <cas...@gmail.com>: >> > >> > I updated to r1570 and tried --enable-fat under mingw32. I get the >> > error listed below. It looks like it trying to use 64-bit assembly. >> > Let me know if you need to see more information. >> > >> > I appreciate the responsiveness of the MPIR developers. >> > >> > Case >> > >> > /bin/sh ../libtool --mode=compile --tag=CC ../strip_fPIC.sh >> > ../yasm/yasm -f elf32 -D >> > GSYM_PREFIX -o amd64_submul_1.lo `test -f 'amd64_submul_1.as' || ec >> > ho './'`amd64_submul_1.as >> > ../strip_fPIC.sh ../yasm/yasm -f elf32 -D GSYM_PREFIX >> > amd64_submul_1.as -o >> > amd64_submul_1.o >> > ../yasm/yasm -f elf32 -D GSYM_PREFIX amd64_submul_1.as -o amd64_submul_1.o >> > /bin/sh ../libtool --tag=CC --mode=compile gcc -std=gnu99 >> > -DHAVE_CONFIG_H -I . -I. -I.. >> > -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fat | sed 's/_$//'` >> > -m32 -O2 -fomit-frame-pointer >> > -mno-cygwin -c -o fat.lo fat.c >> > gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. >> > -DOPERA TION_fat -m32 -O2 >> > -fomit-frame-pointer -mno-cygwin -c fat.c -o fat.o >> > In file included from ../gmp-impl.h:109, >> > from fat.c:31: >> > ../fat.h:261: warning: type defaults to `int' in declaration of >> > `DECL_preinv _add_n' >> > ../fat.h:261: warning: parameter names (without types) in function >> > declarati on >> > ../fat.h:261: warning: data definition has no type or storage class >> > fat.c: In function `__gmpn_cpuvec_init': >> > fat.c:182: error: `CPUVEC_SETUP_x86' undeclared (first use in this >> > function) >> > fat.c:182: error: (Each undeclared identifier is reported only once >> > fat.c:182: error: for each function it appears in.) >> > fat.c:213: error: `CPUVEC_SETUP_pentium' undeclared (first use in this >> > funct >> > >> > On 1/18/09, Bill Hart <goodwillh...@googlemail.com> wrote: >> >> >> >> I don't know what the bug is. Basically even a simple call to mpn_add_n >> >> fails. >> >> >> >> The function is defined by expanding a macro in fat_entry.asm (the >> >> name mpn_add_n comes from a list of functions called CPUVEC_FUNCS_LIST >> >> in /mpn/x86_64/fat/x86_64-defs.m4). >> >> >> >> Essentially in fat_entry.asm, the macro immediately after FAT_INIT >> >> loops through each instruction in CPUVEC_FUNCS_LIST and enters an >> >> offset for it into the cpuvec. >> >> >> >> The macro after FAT_ENTRY loops through each instruction in >> >> CPUVEC_FUNCS_LIST (e.g. __gmpn_add_n) and defines a function of that >> >> name and sets that function up to simply call the function pointer in >> >> the cpuvec. >> >> >> >> What's not clear to me is which functions end up getting called if >> >> there is more than one possibility available for the given processor. >> >> In the case of an AMD64 chip the instructions in /mpn/x86_64 and >> >> /mpn/x86_64/amd64 are both valid. In fat.c the first lot of >> >> instructions are set up automatically. Then when the CPUID returns a >> >> value indicating that an AMD64 chip is available, the latter >> >> instructions are set up. >> >> >> >> I thought the whole idea of a fat binary was that at run time the >> >> fastest instruction for the chip is chosen. But it looks to me like >> >> once _gmpn_cpuvec_init is run, a decision has already been made based >> >> on the CPUID. I guess this makes a portable binary, which is certainly >> >> not faster than just building GMP on the system that you want to run >> >> it on (when function pointers will not be required). >> >> >> >> Anyhow, either the wrong pointers are being put into the cpuvec or the >> >> functions which call the function pointers are broken. That means the >> >> bug is between lines 56 and 154 of fat_entry.asm. But I've been over >> >> the code numerous times and don't see it. There must be something >> >> different about how these pointers are supposed to be computed or >> >> called on a 64 bit machine (I've fixed the obvious - the pointers >> >> should be 64 bits instead of 32). >> >> >> >> Anyone have any ideas? >> >> >> >> Bill. >> >> >> >> 2009/1/19 Bill Hart <goodwillh...@googlemail.com>: >> >> > I fixed cpuid and committed the change. Everything works right through >> >> > to the end of fat.c now. But some of the tests still segfault. >> >> > >> >> > Possibly some of the code in /mpn/x86_64 has bugs. It's never run, as >> >> > everything we build for is either core2 or amd64 if it is 64 bit. Of >> >> > course a fat binary will try to run it. >> >> > >> >> > Bill. >> >> > >> >> > 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >> OK, I rewrote fat.c to work with the x86_64 cpus. This of course made >> >> >> it assemble fat_entry.asm which also requires some macros which were >> >> >> missing from x86_64-defs.m4. I fixed all this. >> >> >> >> >> >> Everything builds now, even make check. But make check segfaults. This >> >> >> will be because of the conversion of fat_entry.asm to 64 bit assembly. >> >> >> It's no doubt broken. It now needs to be rewritten properly. I >> >> >> especially expect that the functions cpuid and cpuid_available are >> >> >> broken. >> >> >> >> >> >> Bill. >> >> >> >> >> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >>> Could that be because they are not declared using the MPN_PROTO >> >> >>> business in gmp-impl.h as I mentioned in a post a couple of days ago? >> >> >>> >> >> >>> Bill. >> >> >>> >> >> >>> 2009/1/18 <ja...@njkfrudils.plus.com>: >> >> >>>> >> >> >>>> On Sunday 18 January 2009 21:25:10 Bill Hart wrote: >> >> >>>> >> >> >>>> runing strings on the libgmp.a I notice we have namespace pollution >> >> >>>> from all >> >> >>>> the new gcd stuff and mpn_modexact_1odd >> >> >>>> >> >> >>>> >> >> >>>> >> >> >>>>> I've checked that exactly the same files are compiled and linked >> >> >>>>> when >> >> >>>>> working on a 64 bit machine as on a 32 bit machine. >> >> >>>>> >> >> >>>>> It looks like gmp-impl.h defines __gmpn_cpuvec as being external. I >> >> >>>>> was wrong about this being defined in fat.h, it is merely used >> >> >>>>> there. >> >> >>>>> >> >> >>>>> The definition of __gmpn_cpuvec is actually in >> >> >>>>> /mpn/x86_64/fat/fat.c. >> >> >>>>> This is defined unconditionally in there, so this file is somehow >> >> >>>>> not >> >> >>>>> being linked into the library on a 64 bit machine. But I still don't >> >> >>>>> know why. >> >> >>>>> >> >> >>>>> Bill. >> >> >>>>> >> >> >>>>> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >>>>> > Nope that wasn't it. I fixed that problem and committed a fix, >> >> >>>>> > but the >> >> >>>>> > original problem still remains. >> >> >>>>> > >> >> >>>>> > Bill. >> >> >>>>> > >> >> >>>>> > 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >>>>> >> I think I have a clue. I can't get any of the tests in >> >> >>>>> >> /tests/mpn to >> >> >>>>> >> work. They all bomb out. >> >> >>>>> >> >> >> >>>>> >> Looking in configure.in I see that for a 32 bit x86 build it puts >> >> >>>>> >> path="x86/fat x86" but for the 64 bit build I had path_64="x86_64 >> >> >>>>> >> x86_64/fat" with the directories in the opposite order. When I >> >> >>>>> >> autoconf and try to configure again it bombs out with: >> >> >>>>> >> >> >> >>>>> >> checking size of mp_limb_t... 8 >> >> >>>>> >> configure: error: Oops, mp_limb_t is 64 bits, but the assembler >> >> >>>>> >> code >> >> >>>>> >> in this configuration expects 32 bits. >> >> >>>>> >> >> >> >>>>> >> So there is something inherently 32 bit about the files in >> >> >>>>> >> /mpn/x86_64/fat (which is not a surprise, as I copied them from >> >> >>>>> >> /mpn/x86/fat). >> >> >>>>> >> >> >> >>>>> >> Probably if we fix this it will work. >> >> >>>>> >> >> >> >>>>> >> Bill. >> >> >>>>> >> >> >> >>>>> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >>>>> >>> Yeah that is interesting. It might be a clue. >> >> >>>>> >>> >> >> >>>>> >>> The funny thing is, everything we need is defined in fat.h >> >> >>>>> >>> (which is >> >> >>>>> >>> created by configure). But fat.h is included by gmp-impl.h if >> >> >>>>> >>> WANT_FAT_BINARY is set, which it is if config.h is included, >> >> >>>>> >>> which it >> >> >>>>> >>> is if we don't have __GMP_WITHIN_CONFIGURE set, which is only >> >> >>>>> >>> set by >> >> >>>>> >>> configure itself when running. >> >> >>>>> >>> >> >> >>>>> >>> So I just don't see why it isn't picking up the requisite stuff >> >> >>>>> >>> from >> >> >>>>> >>> fat.h. >> >> >>>>> >>> >> >> >>>>> >>> Bill. >> >> >>>>> >>> >> >> >>>>> >>> 2009/1/18 <ja...@njkfrudils.plus.com>: >> >> >>>>> >>>> On Sunday 18 January 2009 18:59:46 Bill Hart wrote: >> >> >>>>> >>>>> did it get to addmul or lshift yet? >> >> >>>>> >>>> >> >> >>>>> >>>> I'm not entirely sure , but these are the only functions that >> >> >>>>> >>>> give >> >> >>>>> >>>> errors eg make t-mul in the tests/mpz directory >> >> >>>>> >>>> >> >> >>>>> >>>>> I don't know what is different about them. They are done in a >> >> >>>>> >>>>> pretty >> >> >>>>> >>>>> similar way to addmul_1 and submul_1. >> >> >>>>> >>>>> >> >> >>>>> >>>>> Bill. >> >> >>>>> >>>>> >> >> >>>>> >>>>> 2009/1/18 <ja...@njkfrudils.plus.com>: >> >> >>>>> >>>>> > On Sunday 18 January 2009 18:45:35 Bill Hart wrote: >> >> >>>>> >>>>> >> That's likely because by the time those reference >> >> >>>>> >>>>> >> functions are >> >> >>>>> >>>>> >> used, the actual mpn functions referred to have already >> >> >>>>> >>>>> >> been >> >> >>>>> >>>>> >> tested. >> >> >>>>> >>>>> >> >> >> >>>>> >>>>> >> I don't think this can be the issue anyway, as everything >> >> >>>>> >>>>> >> works >> >> >>>>> >>>>> >> fine on a 32 bit machine. >> >> >>>>> >>>>> >> >> >> >>>>> >>>>> >> The actual error I got was a red herring anyway. The actual >> >> >>>>> >>>>> >> __gmp_cpuvec that we are after is defined in >> >> >>>>> >>>>> >> /mpn/x86_64/fat.c. >> >> >>>>> >>>>> >> Somehow it isn't picking this file up when building >> >> >>>>> >>>>> >> libtests.la or >> >> >>>>> >>>>> >> something in it. >> >> >>>>> >>>>> >> >> >> >>>>> >>>>> >> Bill. >> >> >>>>> >>>>> > >> >> >>>>> >>>>> > make[4]: `libtests.la' is up to date. >> >> >>>>> >>>>> > /bin/sh ../libtool --tag=CC --mode=link gcc -std=gnu99 -O2 >> >> >>>>> >>>>> > -m64 >> >> >>>>> >>>>> > -o t-bswap t-bswap.o libtests.la ../libgmp.la >> >> >>>>> >>>>> > gcc -std=gnu99 -O2 -m64 -o .libs/t-bswap >> >> >>>>> >>>>> > t-bswap.o ./.libs/libtests.a >> >> >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so >> >> >>>>> >>>>> > ../.libs/libgmp.so >> >> >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined >> >> >>>>> >>>>> > reference to >> >> >>>>> >>>>> > `__gmpn_sub_n' >> >> >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined >> >> >>>>> >>>>> > reference to >> >> >>>>> >>>>> > `__gmpn_cpuvec_init' >> >> >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined >> >> >>>>> >>>>> > reference to >> >> >>>>> >>>>> > `__gmpn_cpuvec' >> >> >>>>> >>>>> > /root/mpir/mpir/mpir/trunk/.libs/libgmp.so: undefined >> >> >>>>> >>>>> > reference to >> >> >>>>> >>>>> > `__gmpn_add_n' >> >> >>>>> >>>>> > collect2: ld returned 1 exit status >> >> >>>>> >>>>> > >> >> >>>>> >>>>> > Only add and sub have a problem , not addmul or lshift , >> >> >>>>> >>>>> > whats >> >> >>>>> >>>>> > different about them? >> >> >>>>> >>>>> > >> >> >>>>> >>>>> >> 2009/1/18 <ja...@njkfrudils.plus.com>: >> >> >>>>> >>>>> >> > On Sunday 18 January 2009 17:26:54 Bill Hart wrote: >> >> >>>>> >>>>> >> >> As a further data point make check works on cicero >> >> >>>>> >>>>> >> >> (which is a >> >> >>>>> >>>>> >> >> 32 bit x86 Pentium 4) with --enable-fat. So I don't see >> >> >>>>> >>>>> >> >> why it >> >> >>>>> >>>>> >> >> shouldn't work on a 64 bit machine. >> >> >>>>> >>>>> >> >> >> >> >>>>> >>>>> >> >> Bill. >> >> >>>>> >>>>> >> > >> >> >>>>> >>>>> >> > refmpn.c and refmpf.c have some referances to plain >> >> >>>>> >>>>> >> > mpn_fn , >> >> >>>>> >>>>> >> > change these to refmpn_fn >> >> >>>>> >>>>> >> > >> >> >>>>> >>>>> >> > this clears up some of the errors.... >> >> >>>>> >>>>> >> > >> >> >>>>> >>>>> >> >> 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: >> >> >>>>> >>>>> >> >> > I've hacked up "support" for --enable-fat on x86_64. >> >> >>>>> >>>>> >> >> > It's a >> >> >>>>> >>>>> >> >> > bit hackish (though I think the 32 bit fat support was >> >> >>>>> >>>>> >> >> > already hackish). >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > At this moment however, make check will not build, >> >> >>>>> >>>>> >> >> > with >> >> >>>>> >>>>> >> >> > error: >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > ./.libs/libtests.a(refmpn.o): In function >> >> >>>>> >>>>> >> >> > `refmpn_mod_34lsub1': refmpn.c:(.text+0x1f3): >> >> >>>>> >>>>> >> >> > undefined >> >> >>>>> >>>>> >> >> > reference to `__gmpn_cpuvec' >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > etc. Now refmpn.c #include gmp-impl.h which defines >> >> >>>>> >>>>> >> >> > __gmpn_cpuvec on line 3783 *provided* WANT_FAT_BINARY >> >> >>>>> >>>>> >> >> > is >> >> >>>>> >>>>> >> >> > defined and set (see line 3753). The thing is, make >> >> >>>>> >>>>> >> >> > requires >> >> >>>>> >>>>> >> >> > that to be set in order to build a fat binary in the >> >> >>>>> >>>>> >> >> > first >> >> >>>>> >>>>> >> >> > place. Surely configure configures this the same for >> >> >>>>> >>>>> >> >> > make and >> >> >>>>> >>>>> >> >> > for make check. So I honestly don't know why make >> >> >>>>> >>>>> >> >> > check >> >> >>>>> >>>>> >> >> > fails. If anyone has any insight into this, please >> >> >>>>> >>>>> >> >> > let me >> >> >>>>> >>>>> >> >> > know. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > I'll now mention some of the more hackish aspects of >> >> >>>>> >>>>> >> >> > getting >> >> >>>>> >>>>> >> >> > --enable- fat to work on x86_64: >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > * I removed the check for HAVE_HOST_CPU_FAMILY_x86 on >> >> >>>>> >>>>> >> >> > line >> >> >>>>> >>>>> >> >> > 3753 of gmp- impl.h. This was hackish. Obviously >> >> >>>>> >>>>> >> >> > configure >> >> >>>>> >>>>> >> >> > should not continue if fat binary is not supported on >> >> >>>>> >>>>> >> >> > the >> >> >>>>> >>>>> >> >> > host cpu. It shouldn't be left until this point to >> >> >>>>> >>>>> >> >> > determine >> >> >>>>> >>>>> >> >> > that. I did try to add a >> >> >>>>> >>>>> >> >> > HAVE_HOST_CPU_FAMILY_x86_64 flag, but for some reason >> >> >>>>> >>>>> >> >> > I >> >> >>>>> >>>>> >> >> > couldn't get it to work. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > * I had to put a modified copy of yasm_mac.inc in >> >> >>>>> >>>>> >> >> > /mpn and >> >> >>>>> >>>>> >> >> > /mpn/ x86_64. Now it inserts suffices on function >> >> >>>>> >>>>> >> >> > names when >> >> >>>>> >>>>> >> >> > calling the macro GLOBAL_FUNC. Only when building a >> >> >>>>> >>>>> >> >> > fat >> >> >>>>> >>>>> >> >> > binary does it refer to these copies of yasm_mac.inc >> >> >>>>> >>>>> >> >> > instead >> >> >>>>> >>>>> >> >> > of the one in the root of the source tree, thus >> >> >>>>> >>>>> >> >> > suffices will >> >> >>>>> >>>>> >> >> > not be added for a normal build. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > * I had to copy /mpn/x86/fat/* into /mpn/x86_64/fat. >> >> >>>>> >>>>> >> >> > But note >> >> >>>>> >>>>> >> >> > that I have not defined any 64 bit >> >> >>>>> >>>>> >> >> > family/model/stepping >> >> >>>>> >>>>> >> >> > values in the fake CPUID tables in fat.c as of yet. >> >> >>>>> >>>>> >> >> > This >> >> >>>>> >>>>> >> >> > probably means that the fat binary which is build does >> >> >>>>> >>>>> >> >> > nothing. But someone can add the relevant CPUID >> >> >>>>> >>>>> >> >> > values if >> >> >>>>> >>>>> >> >> > they feel so inspired. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > * Probably a fat binary build on x86_64 doesn't work >> >> >>>>> >>>>> >> >> > on 64 >> >> >>>>> >>>>> >> >> > bit Windows (I'm not talking about MSVC here, but >> >> >>>>> >>>>> >> >> > something >> >> >>>>> >>>>> >> >> > like Cygwin64 if and when it exists). because the >> >> >>>>> >>>>> >> >> > filenames >> >> >>>>> >>>>> >> >> > with suffices are longer than the usual 8.3 format. I >> >> >>>>> >>>>> >> >> > don't >> >> >>>>> >>>>> >> >> > know if this is a problem or not, but it might be. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > * Configure almost certainly can't find functions in >> >> >>>>> >>>>> >> >> > multifunction yasm assembler files implemented with >> >> >>>>> >>>>> >> >> > macros. >> >> >>>>> >>>>> >> >> > It has no idea how to interpret the macro language of >> >> >>>>> >>>>> >> >> > yasm. >> >> >>>>> >>>>> >> >> > Thus functions probably won't be picked up from >> >> >>>>> >>>>> >> >> > multifunction >> >> >>>>> >>>>> >> >> > files. Whilst we use macros, we currently have >> >> >>>>> >>>>> >> >> > separate files >> >> >>>>> >>>>> >> >> > for each of the macro'd functions, so this is >> >> >>>>> >>>>> >> >> > actually not a >> >> >>>>> >>>>> >> >> > problem at present (it infers the function names from >> >> >>>>> >>>>> >> >> > the >> >> >>>>> >>>>> >> >> > filenames alone if they are not actually implemented >> >> >>>>> >>>>> >> >> > as >> >> >>>>> >>>>> >> >> > multifunction files). But it will break when we fix >> >> >>>>> >>>>> >> >> > multifunction support. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > Lots of other hacking was required to get this far. >> >> >>>>> >>>>> >> >> > But the >> >> >>>>> >>>>> >> >> > above is the worst of it. I'll add it to a trac >> >> >>>>> >>>>> >> >> > ticket for >> >> >>>>> >>>>> >> >> > someone with more patience than myself to fix. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > Bill. >> >> >>>>> >>>>> >> >> > >> >> >>>>> >>>>> >> >> > On Jan 15, 1:25 am, "Bill Hart" >> >> >>>>> >>>>> >> >> > <goodwillh...@googlemail.com> >> >> >>>> wrote: >> >> >>>>> >>>>> >> >> >> 2009/1/15 Bill Hart <goodwillh...@googlemail.com>: >> >> >>>>> >>>>> >> >> >> > The problem with --enable-fat on 64 bit systems is >> >> >>>>> >>>>> >> >> >> > that it >> >> >>>>> >>>>> >> >> >> > searches the 64 bit assembly directories for >> >> >>>>> >>>>> >> >> >> > functions but >> >> >>>>> >>>>> >> >> >> > sets the fat directories to the 32 bit x86 >> >> >>>>> >>>>> >> >> >> > directories. >> >> >>>>> >>>>> >> >> >> > This can easily be fixed. Lines 1457-1476 of >> >> >>>>> >>>>> >> >> >> > configure.in >> >> >>>>> >>>>> >> >> >> > need to be replicated for the following case >> >> >>>>> >>>>> >> >> >> > statement >> >> >>>>> >>>>> >> >> >> > which deals with 64 bit machines, but with the >> >> >>>>> >>>>> >> >> >> > correct >> >> >>>>> >>>>> >> >> >> > directories set. >> >> >>>>> >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> Actually this won't quite directly work. The reason >> >> >>>>> >>>>> >> >> >> is that >> >> >>>>> >>>>> >> >> >> in order to determine which functions it should >> >> >>>>> >>>>> >> >> >> include in >> >> >>>>> >>>>> >> >> >> the fat binary, it looks for PROLOGUE(mpn_fnname) in >> >> >>>>> >>>>> >> >> >> the >> >> >>>>> >>>>> >> >> >> assembly files. We don't use that macro in the x86_64 >> >> >>>>> >>>>> >> >> >> assembly code (which is in yasm format). >> >> >>>>> >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> We could fix this by modifying what it looks for >> >> >>>>> >>>>> >> >> >> appropriately on x86_64. We should be looking for >> >> >>>>> >>>>> >> >> >> GLOBAL_FUNC mpn_fnname instead. >> >> >>>>> >>>>> >> >> >> >> >> >>>>> >>>>> >> >> >> Bill. >> >> >>>>> >> >> >>>>> >> >> >>>> >> >> >>>> >> >> >>>> >>>> >> >> >>>> >> >> >>> >> >> >> >> >> > >> >> >> >> > >> >> >> > >> > > >> > >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---