Sat, 9 Jun 2012 20:00:37 +0100
Jason Moxham wrote:
> I had a quick read of the license and it's nothing special , so
> mingw64 users probably wont have an objection , but I can imagine
> other (linux users for example)people who will object to downloading
> a package which contains some parts whi
On Sat, 9 Jun 2012 20:00:37 +0100
Jason Moxham wrote:
> I had a quick read of the license and it's nothing special , so
> mingw64 users probably wont have an objection , but I can imagine
> other (linux users for example)people who will object to downloading
> a package which contains some parts
I had a quick read of the license and it's nothing special , so mingw64 users
probably wont have an objection , but I can imagine other (linux users for
example)people who will object to downloading a package which contains some
parts which have a "commercial" license even though they won't be u
On Sat, 9 Jun 2012 18:30:31 +0100
Jason Moxham wrote:
> Hm , I just assumed yasm supported masm but it's nasm . What we
> need is a masm compatible free/open source program that I can get to
> work under mingw64 then. Getting it to work under mingw64 should be
> easy.We can get rid of yasm an
On Sat, 9 Jun 2012 20:48:13 +0300
degski wrote:
> >
> >
> > I am not pushing to move away from YASM but if we want to reduce our
> > dependence on non-native tools and YASM in particular, then using
> > GAS on Unix/Linux and MASM on Windows makes sense as this would
> > allow 'out of the box' bui
>
>
> I am not pushing to move away from YASM but if we want to reduce our
> dependence on non-native tools and YASM in particular, then using GAS
> on Unix/Linux and MASM on Windows makes sense as this would allow 'out
> of the box' builds on both Unix/Linux and Windows.
>
It is already not possi
On Sat, 9 Jun 2012 18:30:31 +0100
Jason Moxham wrote:
> Hm , I just assumed yasm supported masm but it's nasm . What we
> need is a masm compatible free/open source program that I can get to
> work under mingw64 then. Getting it to work under mingw64 should be
> easy.We can get rid of yasm an
As for the maintenance burden for mingw64 , it's been zero , the current
mingw64 compilers are broken , and the redc_2 include gmp.h rather than mpir.h
wouldn't be picked up in linux builds as all distributions of linux have gmp.h
in the path , I would of picked it up on mingw64 if at the time I
Hm , I just assumed yasm supported masm but it's nasm . What we need is a
masm compatible free/open source program that I can get to work under mingw64
then. Getting it to work under mingw64 should be easy.We can get rid of yasm
and use gas under linux and masm under msvc and this new ?asm?
On Sat, 9 Jun 2012 17:53:49 +0100
Jason Moxham wrote:
> What I'm saying that if msvc wants to go the masm route then I'm sure
> I can get mingw64 to work with those source files , we would of
> course need the path in mingw64 to specify where masm was , or
> perhaps if we keep the masm macros sim
That sounds like it might be a good plan. But I do want to make sure I
can build MPIR on MinGW64 without MASM, as I currently don't seem to
have a copy and there are no free alternatives (though the Yasm format
isn't that dissimilar, as you say).
Bill.
On 9 June 2012 17:53, Jason Moxham wrote:
>
What I'm saying that if msvc wants to go the masm route then I'm sure I can get
mingw64 to work with those source files , we would of course need the path in
mingw64 to specify where masm was , or perhaps if we keep the masm macros
simple (like we do anyway) then even the current mingw64 yasm wi
Hi
On Linux/cygwin/mingw32 we currently use both yasm and gas to build assembler
files , yasm to build intel format and gas to build AT&T format , I also got
some patches so we can use either always yasm or always gas without any changes
to the source files , so we could get rid of yasm or not
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-
On Sat, 9 Jun 2012 09:54:38 +0100
Jason Moxham wrote:
> On Sat, 9 Jun 2012 09:14:51 +0100
> Jason Moxham wrote:
>
> > This is based on the 2.5.1 branch
>
> Thanks Jason, I have just downloaded it and saw that it is a minor
> evolution of 2.5.1.
>
> I assume that when 2.5.1 was branched fro
On Sat, 9 Jun 2012 09:14:51 +0100
Jason Moxham wrote:
> This is based on the 2.5.1 branch
Thanks Jason, I have just downloaded it and saw that it is a minor
evolution of 2.5.1.
I assume that when 2.5.1 was branched from trunk, it worked on MSVC.
So what matters are any post release patches
On Sat, 9 Jun 2012 09:14:51 +0100
Jason Moxham wrote:
> This is based on the 2.5.1 branch
Thanks Jason, I have just downloaded it and saw that it is a minor
evolution of 2.5.1.
I assume that when 2.5.1 was branched from trunk, it worked on MSVC.
So what matters are any post release patches
This is based on the 2.5.1 branch
Jason
--
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
On Sat, 9 Jun 2012 08:32:32 +0100
Jason Moxham wrote:
> I'll change the website and tested the fallbacks for the broken
> debian gcc-4.3.2
>
> Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Is this our next release or one we have already issued?
I don't normally work from
I'll change the website and tested the fallbacks for the broken debian gcc-4.3.2
Brian , is there any msvc changes needed for the mpir-2.5.2 branch?
Jason
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To post to this group, send email to mpir-
20 matches
Mail list logo
