sorry that should be /mpn/x86_64/fat/fat.c 2009/1/18 Bill Hart <goodwillh...@googlemail.com>: > 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. > > 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 -~----------~----~----~----~------~----~------~--~---
