On Sep 4, 9:34 pm, Cactus <rieman...@gmail.com> wrote: > On Sep 4, 9:04 pm, Jason <ja...@njkfrudils.plus.com> wrote: > > > > > > > On Saturday 28 August 2010 11:56:18 jason wrote: > > > > ----- Original Message ----- > > > From: "Cactus" <rieman...@gmail.com> > > > To: "mpir-devel" <mpir-devel@googlegroups.com> > > > Sent: Saturday, August 28, 2010 10:27 AM > > > Subject: [mpir-devel] Re: mingw64 > > > > On Aug 28, 9:59 am, "jason" <ja...@njkfrudils.plus.com> wrote: > > > > Hi > > > > > I think I know why the mingw64 dll builds fail , for multiple functions > > > > files ie aors_err2_n.asm , in the MSVC build yasm emits both functions > > > > in > > > > a single "unit" , whereas under mingw64 we create two links add and sub > > > > versions (like we do for unix) , and also yasm still emits both > > > > functions > > > > , so we end up with two copys. The same must happen in the static build > > > > , > > > > but it doesn't seem to matter? > > > > I was planning to get rid of such complications ( or rather move them to > > > > development machines only , much like autotools generates Makefile.in) , > > > > a small script should easily take of it. > > > If we do it that way , then the x86_64w asm files with multifunction files > > ie > > aors_err1.asm will need to have the same m4 macro's as the linux ones. It's > > probably easier just to get rid of them altogether (not even a pre-dist > > stage) > > For the time being we only need to remove the x86_64 and x86_64w ones , we > > can > > leave the other cpu's to later. For x86_64 we only have two of them anyway > > aors_err1_n and aors_err2_n , and I think x86_64w is the same. Note this > > still leaves the alternative entry point functions ie addlsh_n and > > addlsh_nc , > > but for linux at least this is automatic , and we dont need any configure > > magic > > for it.This at least gets us part way towards our goal. > > > > I wwould be very happy to make several changes that are related to > > > this issue, all of which would make all the Windows builds much > > > easier: > > > > 1. All files emit only one routine and only one symbol (this would > > > expand the source for some 'carry in' and 'no carry in' variants); > > > ----------------------- > > > I was hoping to keep files with multiple entry points , but yeah , I cant > > > see how we can do it in general. For the add_n and add_nc we could do it > > > with macros , but for the divide it's a bit harder , and we might need to > > > maintain the function version for full backwards dll compatibility. > > > -------------- > > > 2. A strict equality between C and assembler file names and the > > > symbols they emit (ignoring the prefix); > > > 3. A new extension (i.e not c, cc, as, asm, ..) for files that are > > > not compiled directly but are included in other files. > > > ---------------------- > > > makes sense > > > --------------------- > > > I don't think it matters issuing HAVE_NATIVE defines for all assembler > > > symbols even if they aare complete C replacements so we can (I think) > > > ignore this. > > > ------------------------ > > > I think we may have to keep some , mainly for those combined functions > > > that > > > would require temp space if we dont have a native one > > > ------------------------ > > > This would allow a major simplification in the Windows builds since it > > > would then be possible to generate most of the build files > > > automatically for any Windows build tools. > > > ----------------------- > > > yeah > > > ----------------------- > > > > > For the t-locale test , is there no way that MSVC will pass it ? , if so > > > > I'll ifdef it out , with ! _MSC_VER , because under mingw I think I can > > > > get it to pass , it looks like the redefinition of localenv just needs a > > > > DECLSPEC > > > > I haven't tried a DECLSPEC - I see if it works. > > > > -------------------- > > > I get a different error message now , it did say something like declspec > > > doesn't match , I think this is due to my change of config guess , before > > > I > > > had to force it , and maybe that changed one of the lib search paths? > > > ----------------------------- > > > > --------------------------- > > > > Brian > > Hi Jason, > > I don't really understand this. > > I assumed that we put these into assembler because their speed matters > but you are now saying we can do without them. > > But this doesn't make sense - why did we bother with them in the first > place? > > What is wrong with the two files solution - files for add and subtract > that use a common include file that contains the 'aors' code? > > Brian
I can see that you have just done this in x86_64 - do you want me to do it in x86_64w? Brian -- You received this message because you are subscribed to the Google Groups "mpir-devel" group. To post to this group, send email to mpir-de...@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.
