Hey Brian. Could you announce on this list when you have a MSYS working for
Windows 7 64-bit.
Regards
Chris Saunders
--------------------------------------------------
From: "Cactus" <rieman...@gmail.com>
Sent: Saturday, August 28, 2010 7:29 AM
To: "mpir-devel" <mpir-devel@googlegroups.com>
Subject: [mpir-devel] Re: mingw64
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?
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.
--
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.
