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