On Saturday 28 August 2010 12:29:56 Cactus wrote: > On Aug 28, 11:56 am, "jason" <ja...@njkfrudils.plus.com> 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. > > > > 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 > > Sorry Jason - I think I phrased this badly. I wasn't suggesting that > we remove any but rather just issuing HAVE_NATIVE defines for all > assembler code symbols on the assumption that symbols from files that > are complete replacements for C files will exist but won't be used. > But, maybe I am wrong about this? >
I'm not totally sure what we do , the only time we really need them is where the existence of a function on one cpu is a win , but on another cpu it would be a lose. > Interestingly a further simplification of the Windows build would be > to add a guard in C files with complete assembler replacements to > remove all the code - they would then be included but be empty and I > would not have to manually exclude them as I do now. > > 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.
