On 9 June 2012 20:00, 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 which have
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
Ah yes, I see now. The symbols need to have the global symbol prefix.
And indeed someone needs to ensure the right macro is called in each
file.
This could potentially be an explanation for the bug that was
reported. I'll look into that.
And just to confirm, mingw is definitely still supported. J
On Thu, 24 May 2012 14:18:04 +0100
Bill Hart wrote:
> Are you sure about this?
>
> I thought the MSVC build used yasm? Well, so does the MinGW one.
>
> If the files build for MSVC, they should build for MinGW, as it is the
> same assembler.
>
> I am sure it is some trivial bug introduced in 2.
Are you sure about this?
I thought the MSVC build used yasm? Well, so does the MinGW one.
If the files build for MSVC, they should build for MinGW, as it is the
same assembler.
I am sure it is some trivial bug introduced in 2.5.1. Let's wait until
Jason has time to take a look. In the mean time,
On Thu, 24 May 2012 09:55:08 +0900
Pavel Holoborodko wrote:
> Just my two cents. The latest official version of MPIR 2.5.1 doesn't
> compile using mingw64 (as well as version from SVN).
> MPIR 2.5.0 compiles fine. Is mingw64 support already dropped?
Hi Pavel,
I can only say that I have never su
Just my two cents. The latest official version of MPIR 2.5.1 doesn't
compile using mingw64 (as well as version from SVN).
MPIR 2.5.0 compiles fine. Is mingw64 support already dropped?
I've described this problem few days ago, but nobody replied:
https://groups.google.com/group/mpir-devel/browse_th
On Wed, 23 May 2012 10:32:23 +0300
degski wrote:
> Dear ALL,
>
> I have been using Dr. Gladman's msvc build-projects for a long time,
> and followed his move with MPIR as from the start... What I cannot
> follow anymore and this does not only apply to this thread, but
> others in the past as wel
Dear ALL,
I have been using Dr. Gladman's msvc build-projects for a long time, and
followed his move with MPIR as from the start... What I cannot follow
anymore and this does not only apply to this thread, but others in the past
as well, is that the reason for Brian's work was to make it possible
On Tue, 22 May 2012 19:08:02 +0100
Bill Hart wrote:
> On Tuesday, 22 May 2012, Bill Hart
> wrote:
> >
> >
> > On Tuesday, 22 May 2012, Jeroen Demeyer
> > wrote:
> >> On 2012-05-22 15:37, Bill Hart wrote:
> >>> We could then
> >>> ditch building Yasm on Linux, which would save some headaches for
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
>> On 2012-05-22 15:37, Bill Hart wrote:
>>> We could then
>>> ditch building Yasm on Linux, which would save some headaches for
>>> Sage.
>> I don't really think that yasm is a problem for Sage. It's
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
>> On 2012-05-22 15:37, Bill Hart wrote:
>>> We could then
>>> ditch building Yasm on Linux, which would save some headaches for
>>> Sage.
>> I don't really think that yasm is a problem for Sage. It's
On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
> On 2012-05-22 15:37, Bill Hart wrote:
>> We could then
>> ditch building Yasm on Linux, which would save some headaches for
>> Sage.
> I don't really think that yasm is a problem for Sage. It's true that
> sometimes a Sage build might build because
On Tuesday, 22 May 2012, Jeroen Demeyer wrote:
> On 2012-05-22 15:37, Bill Hart wrote:
>> We could then
>> ditch building Yasm on Linux, which would save some headaches for
>> Sage.
> I don't really think that yasm is a problem for Sage. It's true that
> sometimes a Sage build might build because
On 2012-05-22 15:37, Bill Hart wrote:
> We could then
> ditch building Yasm on Linux, which would save some headaches for
> Sage.
I don't really think that yasm is a problem for Sage. It's true that
sometimes a Sage build might build because of a problem with yasm, but
it's more because MPIR/YASM
On Tuesday, 22 May 2012, Bill Hart wrote:
>
>
> On Tuesday, 22 May 2012, Brian Gladman wrote:
>> On Tue, 22 May 2012 16:53:07 +0100
>> Bill Hart wrote:
>>
>>> On 22 May 2012 16:37, Brian Gladman wrote:
>>> > On Tue, 22 May 2012 15:19:52 +0100
>>> > Bill Hart wrote:
>>> >
>>> >> Well spotted. I
On Tuesday, 22 May 2012, Brian Gladman wrote:
> On Tue, 22 May 2012 16:53:07 +0100
> Bill Hart wrote:
>
>> On 22 May 2012 16:37, Brian Gladman wrote:
>> > On Tue, 22 May 2012 15:19:52 +0100
>> > Bill Hart wrote:
>> >
>> >> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not
>> >>
On Tue, 22 May 2012 16:53:07 +0100
Bill Hart wrote:
> On 22 May 2012 16:37, Brian Gladman wrote:
> > On Tue, 22 May 2012 15:19:52 +0100
> > Bill Hart wrote:
> >
> >> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not
> >> the linux assembly code. So indeed, for MinGW support, we
On 22 May 2012 16:37, Brian Gladman wrote:
> On Tue, 22 May 2012 15:19:52 +0100
> Bill Hart wrote:
>
>> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
>> linux assembly code. So indeed, for MinGW support, we probably have
>> little choice but to use a portable assembler. So
On Tue, 22 May 2012 15:19:52 +0100
Bill Hart wrote:
> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
> linux assembly code. So indeed, for MinGW support, we probably have
> little choice but to use a portable assembler. So it looks like we are
> stuck with Yasm, unless we w
On Tue, 22 May 2012 15:20:53 +0100
Bill Hart wrote:
> We could still use GCC only on linux. But we'd have to be careful that
> yasm still got built on MinGW.
That would depend on which assembler code mingw64 uses - if it uses my
assembler code and I move to MASM, it might get left 'high and dry'
We could still use GCC only on linux. But we'd have to be careful that
yasm still got built on MinGW.
Bill.
On 22 May 2012 15:19, Bill Hart wrote:
> Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
> linux assembly code. So indeed, for MinGW support, we probably have
> littl
Well spotted. Indeed, MinGW64 uses the Windows assembly code, not the
linux assembly code. So indeed, for MinGW support, we probably have
little choice but to use a portable assembler. So it looks like we are
stuck with Yasm, unless we wanted to duplicate all the Windows
assembly code (something I
On Tue, 22 May 2012 14:37:26 +0100
Bill Hart wrote:
> I agree with that explanation. However, I should add that it is
> largely for historical reasons.
>
> MPIR originally planned to support MSVC out-of-the-box (as did Sage
> once). One reason for this is that many Windows developers use MSVC.
>
I agree with that explanation. However, I should add that it is
largely for historical reasons.
MPIR originally planned to support MSVC out-of-the-box (as did Sage
once). One reason for this is that many Windows developers use MSVC.
Brian Gladman has been successfully providing that ability (actua
On Tue, 22 May 2012 11:14:51 +0200
Jeroen Demeyer wrote:
> What is the reason that MPIR uses yasm to build *some* of its assembly
> files? It seems that most assembly files are built using gcc, i.e.
> the system assembler. Why use two different assemblers?
Originally it was hoped that using YA
What is the reason that MPIR uses yasm to build *some* of its assembly
files? It seems that most assembly files are built using gcc, i.e. the
system assembler. Why use two different assemblers?
--
You received this message because you are subscribed to the Google Groups
"mpir-devel" group.
To
39 matches
Mail list logo
