shington
>> > machines , did that ever happen?
>> >
>> > Jason
>> >
>> >> There are a few projects I use that think they dont need to do tested
>> >> releases , and they are a pain in the arse to use because it next to
>> >> impossible to kee
use that think they dont need to do tested
>> releases , and they are a pain in the arse to use because it next to
>> impossible to keep things consistent.
>>
>> Jason
>>
>> - Original Message -
>> From: "Case Vanhorsen"
>> To:
>>
are a few projects I use that think they dont need to do tested
> >> releases , and they are a pain in the arse to use because it next to
> >> impossible to keep things consistent.
> >>
> >> Jason
> >>
> >> - Original Message -
> >> From:
that think they dont need to do tested
> releases , and they are a pain in the arse to use because it next to
> impossible to keep things consistent.
>
> Jason
>
> - Original Message -
> From: "Case Vanhorsen"
> To:
> Sent: Monday, November 08, 2010 6:24 PM
&g
think they dont need to do tested
releases , and they are a pain in the arse to use because it next to
impossible to keep things consistent.
Jason
- Original Message -
From: "Case Vanhorsen"
To:
Sent: Monday, November 08, 2010 6:24 PM
Subject: Re: [mpir-devel] Re: cygwin fail
I have seen issues similar to this with mingw32. The solution was to
use an old MSYS version (1.0.10 IIRC) instead of the latest
version(s). I just assumed it was a quirk in the version of MSYS I
used so I didn't persue it any further.
casevh
--
You received this message because you are subscrib
I installed gcc-4.3.4 on cygwin , which would always bomb out the
install before , and trying it with that I get this error
/bin/sh ../libtool --tag=CC --mode=compile gcc-4 -std=gnu99 -
DHAVE_CONFIG_H -I
. -I../../mpn -I.. -D__GMP_WITHIN_GMP -I../.. -DOPERATION_`echo
fib2_ui | sed 's
/_$//'`
That's not the complete solution as it broke the generic C build with
gcc-3.4 , I think it may be best to wait until mpir-1.4 for this fix ,
it just takes too long to test them , cygwin autotools is broken so I
have to do it on another machine , transfer it to a windows box , and
then wait 2 hour
Thanks
In the svn trunk I have enabled auto import , this fixes the gcc-4 issue ,
hopefully it does not break anything else. I'm running some tests now , but
cygwin is very very slow to build so it will take a few hours.
Jason
On Thursday 22 October 2009 21:15:46 Dan Grayson wrote:
> That's
That's cygwin 1.5. The gcc4 package is a standard one on the list
when running "setup", so any user of cygwin might have installed it,
and it might be worthwhile taking its possible presence into account,
to save the user some debugging time.
On Oct 22, 11:37 am, Jason Moxham wrote:
> On Thursd
On Thursday 22 October 2009 15:42:05 Dan Grayson wrote:
> To get mpir to pass its C++ tests under cygwin (if I configure with --
> enable-cxx) I had to also add -Wl,--enable-auto-import to LDFLAGS.
> The warning message from ld if you don't have that option specified
> doesn't sound very scary, be
On Fri, Apr 10, 2009 at 3:28 PM, Bill Hart wrote:
> ld -v
>
> On my system it returns:
> GNU ld (GNU Binutils) 2.18.50.20080625
>
> Assuming it returns the same on yours, then I'm pretty sure that is
> not the cause of the trouble you originally reported.
Yes mine is identical.
> I'll consider
Thanks Jeff. This now agrees with what I am getting.
My guess is that we used a different autoconf to build the latest RC
and that deals correctly with Cygwin.
We'll keep an eye on this in future releases. I can check that Cygwin
works on my machine, for example.
Your config.guess script is cor
On Fri, Apr 10, 2009 at 4:36 AM, Bill Hart wrote:
> Hi Jeff. I didn't manage to reproduce the Cygwin32 issue with
> mpir-1.0, even with a core 2 build, yet. I'm going to try 0.9 now to
> see if an earlier version of 1.0 might have had the bug (which would
> presumably be present in 0.9).
I don'
Also no issues with 0.9. So I've drawn a blank on this one.
Bill.
2009/4/10 Bill Hart :
> Hi Jeff. I didn't manage to reproduce the Cygwin32 issue with
> mpir-1.0, even with a core 2 build, yet. I'm going to try 0.9 now to
> see if an earlier version of 1.0 might have had the bug (which would
>
Hi Jeff. I didn't manage to reproduce the Cygwin32 issue with
mpir-1.0, even with a core 2 build, yet. I'm going to try 0.9 now to
see if an earlier version of 1.0 might have had the bug (which would
presumably be present in 0.9).
Is there any chance you could check out trunk from svn:
http://mo
No problems. Glad to hear it is resolved!! We can resolve this ticket it looks.
Bill.
2009/4/10 Case Vanhorsen :
>
> On Thu, Apr 9, 2009 at 10:57 PM, Bill Hart
> wrote:
>>
>> No issues with a Core 2 build.
>>
>> I'll now try MPIR 1.0 and see if the issue occurs with that version
>> instead of
On Thu, Apr 9, 2009 at 10:57 PM, Bill Hart wrote:
>
> No issues with a Core 2 build.
>
> I'll now try MPIR 1.0 and see if the issue occurs with that version
> instead of trunk.
>
> Bill.
>
> 2009/4/10 Bill Hart :
>> No issues with trunk on the latest Cygwin. Now trying a Core 2 build.
>>
>> Is it
No issues with a Core 2 build.
I'll now try MPIR 1.0 and see if the issue occurs with that version
instead of trunk.
Bill.
2009/4/10 Bill Hart :
> No issues with trunk on the latest Cygwin. Now trying a Core 2 build.
>
> Is it possible we have fixed the issues that were reported on Cygwin32 in
No issues with trunk on the latest Cygwin. Now trying a Core 2 build.
Is it possible we have fixed the issues that were reported on Cygwin32 in trunk?
Bill.
2009/4/10 Bill Hart :
> I finally got MSYS/MinGW working on my machine. There were errors all
> the way through the MSYS installation proc
I finally got MSYS/MinGW working on my machine. There were errors all
the way through the MSYS installation procedure, but I could
eventually get it to install and it did build MPIR.
Both and ordinary build and a fat binary build work and pass make
check. Most of the yasm tests fail, but yasm its
On Apr 9, 9:37 am, Bill Hart wrote:
> Can you give me a link to the site. I think I am getting it from the
> wrong place.
Sorry for the daly Bill but I have been travelling since 9:30 this
morning and have only just got off the road.
I think I just followed the instrructions here:
http://www
That's really, really odd. Why does their new assembler not know how
to deal with relocations?
At least I can update my Cygwin and try to replicate the issue you are having.
Thanks for the information. Hopefully we'll get somewhere with it now.
Bill.
2009/4/9 Jeff Gilchrist :
>
> On Thu, Apr 9
On Thu, Apr 9, 2009 at 7:13 AM, Bill Hart wrote:
> That's interesting. My Cygwin uses (gcc -v):
>
> gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
>
> It looks like it was installed November 2007, so about 18 months old.
> I've not done anything special to it, such as installing
That's interesting. My Cygwin uses (gcc -v):
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
It looks like it was installed November 2007, so about 18 months old.
I've not done anything special to it, such as installing gcc version
4.
I may have installed development headers of s
On Thu, Apr 9, 2009 at 4:14 AM, Bill Hart wrote:
> I'm going to downgrade the bug we have listed in trac for cygwin32
> from a blocker, as it only appears to affect old versions of Cygwin.
> I'm not totally sure we can do anything for such setups.
The cygwin I have that is experiencing this pro
Can you give me a link to the site. I think I am getting it from the
wrong place.
I put msys on my system and there was no gcc. So I put mingw on, but
when I ran gcc it just said "no input files". It didn't matter what I
tried to compile, I got the same message.
I then found that I was supposed
On Apr 9, 9:30 am, Bill Hart wrote:
> Ah, indeed I didn't read the failure log correctly. It was mingw32.
>
> So I really have to get that going on my system somehow.
>
> Does anyone know where I can download a working version of Mingw32
> that is easy to install and has a working gcc for Vista
On Apr 9, 9:27 am, Bill Hart wrote:
> Oh, have I got this mixed up? I assumed it was ming64 that we had the
> --enable-fat issue. It was on Windows 2000 if I recall. Could it have
> been mingw32 on Windows 2000?
I am afraid I didn't get involved in this issue so I don't know the
answer.
B
Ah, indeed I didn't read the failure log correctly. It was mingw32.
So I really have to get that going on my system somehow.
Does anyone know where I can download a working version of Mingw32
that is easy to install and has a working gcc for Vista 32 bits?
Bill.
2009/4/9 Bill Hart :
> Oh, have
Oh, have I got this mixed up? I assumed it was ming64 that we had the
--enable-fat issue. It was on Windows 2000 if I recall. Could it have
been mingw32 on Windows 2000?
Bill.
2009/4/9 Cactus :
>
>
>
> On Apr 9, 9:14 am, Bill Hart wrote:
>> I fixed a bug in fat.c in the x86 directory (replace a
On Apr 9, 9:14 am, Bill Hart wrote:
> I fixed a bug in fat.c in the x86 directory (replace athlon with k8)
> and on cygwin32 MPIR builds and passes make check. The fat binary also
> builds and passes make check.
>
> I'm going to downgrade the bug we have listed in trac for cygwin32
> from a blo
32 matches
Mail list logo
