On Aug 29, 11:31 pm, "Chris Saunders" <[email protected]> wrote:
> Hey Brian. Could you announce on this list when you have a MSYS working for
> Windows 7 64-bit.
>
> Regards
> Chris Saunders
>
> --------------------------------------------------
> From: "Cactus" <[email protected]>
> Sent: Saturday, August 28, 2010 7:29 AM
> To: "mpir-devel" <[email protected]>
> Subject: [mpir-devel] Re: mingw64
>
>
>
>
>
> > On Aug 28, 11:56 am, "jason" <[email protected]> wrote:
> >> ----- Original Message -----
> >> From: "Cactus" <[email protected]>
> >> To: "mpir-devel" <[email protected]>
> >> Sent: Saturday, August 28, 2010 10:27 AM
> >> Subject: [mpir-devel] Re: mingw64
>
> >> On Aug 28, 9:59 am, "jason" <[email protected]> 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?
>
> > 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 [email protected].
> > To unsubscribe from this group, send email to
> > [email protected].
> > For more options, visit this group at
> >http://groups.google.com/group/mpir-devel?hl=en.
Hi Chris
Jason is leading on the MPIR mingw64 port so I'll have to leave him to
announce this when is happy with it.
Brian
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/mpir-devel?hl=en.
