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