Progress. I discovered that fat.c is built because it is listed in extra_functions. However for a 64 bit build this needs to be extra_functions_64 in configure.in. I've fixed that and now it tries to build fat.c, which of course fails with:
/bin/bash ../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_`echo fat | sed 's/_$//'` -O2 -m64 -c -o fat.lo fat.c gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I. -I.. -D__GMP_WITHIN_GMP -I.. -DOPERATION_fat -O2 -m64 -c fat.c -fPIC -DPIC -o .libs/fat.o 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 function) fat.c:217: error: 'CPUVEC_SETUP_pentium_mmx' undeclared (first use in this function) fat.c:223: error: 'CPUVEC_SETUP_p6' undeclared (first use in this function) fat.c:227: error: 'CPUVEC_SETUP_p6_mmx' undeclared (first use in this function) fat.c:232: error: 'CPUVEC_SETUP_p6_p3mmx' undeclared (first use in this function) fat.c:238: error: 'CPUVEC_SETUP_pentium4' undeclared (first use in this function) fat.c:239: error: 'CPUVEC_SETUP_pentium4_mmx' undeclared (first use in this function) fat.c:240: error: 'CPUVEC_SETUP_pentium4_sse2' undeclared (first use in this function) fat.c:256: error: 'CPUVEC_SETUP_k6' undeclared (first use in this function) fat.c:257: error: 'CPUVEC_SETUP_k6_mmx' undeclared (first use in this function) fat.c:261: error: 'CPUVEC_SETUP_k6_k62mmx' undeclared (first use in this function) fat.c:272: error: 'CPUVEC_SETUP_k7' undeclared (first use in this function) fat.c:273: error: 'CPUVEC_SETUP_k7_mmx' undeclared (first use in this function) make[2]: *** [fat.lo] Error 1 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 -~----------~----~----~----~------~----~------~--~---
