It might be. We have a script which runs in release versions only which
fixes a few problems. But I don't know the answer to your question for sure.
Bill.
On 15 May 2013 03:00, Alessandro "Jake" Andrioni wrote:
> Curiously, the stable 2.6.0 version doesn't try to install yasm
> binaries and he
Curiously, the stable 2.6.0 version doesn't try to install yasm
binaries and headers, but the master from Github does try. Is this
intentional?
On 14 May 2013 12:41, Bill Hart wrote:
> I don't think we have an option to use the system yasm at present.
>
> Bill.
>
>
> On 14 May 2013 14:01, Alessan
I don't think we have an option to use the system yasm at present.
Bill.
On 14 May 2013 14:01, Alessandro "Jake" Andrioni wrote:
> Ok, thanks, then I'm going to patch it myself for now.
>
> Is there a way to use a system yasm? The yasm binaries and headers
> conflict with the system ones right
Ok, thanks, then I'm going to patch it myself for now.
Is there a way to use a system yasm? The yasm binaries and headers
conflict with the system ones right now.
On 14 May 2013 09:38, Bill Hart wrote:
> Oh I'm sorry, I misread that as a failure in t-root. Yes, you are right it
> is the same bug
Oh I'm sorry, I misread that as a failure in t-root. Yes, you are right it
is the same bug as Dan reported.
It will be patched in the next release.
Bill.
On 14 May 2013 13:11, Alessandro Andrioni wrote:
> It seems to be the exact same error from
> https://groups.google.com/forum/?hl=en&fromgr
It seems to be the exact same error from
https://groups.google.com/forum/?hl=en&fromgroups=#!topic/mpir-devel/oLk3gMULxu0
Any
plans for patching it in the git repository? I'm writing a PKBGUILD (so
it's easy to install and manage in Arch Linux) for the git version of mpir,
so I can it patch th
Yes of course you're right, I don't have gcc 4.5.1, I have gcc 4.3.4.
I incorrectly assumed that I had 4.5.1 because I installed gcc only
this past month.
On Feb 10, 3:24 pm, Jason wrote:
> On Thursday 10 February 2011 18:56:58 jason wrote:
>
> > Hi
>
> > I just updated my cygwin on Vista 64 to t
On Thursday 10 February 2011 18:56:58 jason wrote:
> Hi
>
> I just updated my cygwin on Vista 64 to the latest and now its back
> working again(it continued to work on Vista32, weird!)
> gcc-3.4.4 works OK and so does gcc-4.3.4 , yet to try 4.5.1 , as it
> cant find the c++ compiler for some reaso
Hi
I just updated my cygwin on Vista 64 to the latest and now its back
working again(it continued to work on Vista32, weird!)
gcc-3.4.4 works OK and so does gcc-4.3.4 , yet to try 4.5.1 , as it
cant find the c++ compiler for some reason.
Jason
On Feb 10, 4:55 pm, CTSmith wrote:
> In the option
In the options, I reduced my previous configure from
./configure --enable-gmpcompat --enable-cxx=detect --enable-assert
to
./configure --enable-gmpcompat --enable-cxx=detect.
This was successful. It seems that the only bug is in assertion
checking.
Jason, I am indeed using gcc 4.5. Hopefully this
Alright, now the make check makes it down to .../tests/cxx, and fails
there.
Here is the part of the message that applies:
...
Making check in cxx
make[3]: Entering directory '/cygdrive/c/mpir/mpir-2.2.1/tests/cxx'
make t-assign.exe t-binary.exe t-cast.exe t-constr.exe t-headers.exe
t-istream.
e
A pure guess, Windows is running out of memory when running the test.
I might be wrong, however, I think it writes some really large strings
when it does the tests. Cygwin might not like that.
Bill.
On 8 February 2011 19:32, CTSmith wrote:
> Bill,
>
> Thanks for your response!
> You know, it's f
Bill,
Thanks for your response!
You know, it's funny, but I'd run it twice when i posted the thread. I
decided, 'what the heck, 3rd time's the charm' and ran it a third
time. This time it passed. Perhaps there was interference of some
sort, but I can't make sense of it... anyways, I'll still give
> > On the same topic, in the 1.3.0-rc1 manual, mpz_nextprime and
> > mpz_probab_prime_p are tagged "obsolete", whereas in gmp manual they are
> > still perfectly valid functions. I suggest to also add these "before
> > fork" symbols when gmpcompat is active.
> >
>
> The functions will be availab
On Tuesday 20 October 2009 19:02:37 Pierrick Gaudry wrote:
> On Tue, Oct 20, 2009 at 06:18:42PM +0100, Jason Moxham wrote:
> > Some of them are so old they are not in the gmp manual anyway :) , some
> > were from gmp version 1 or 2 back in 93?94? , perhaps we should just
> > define them with confi
On Tue, Oct 20, 2009 at 06:18:42PM +0100, Jason Moxham wrote:
> Some of them are so old they are not in the gmp manual anyway :) , some were
> from gmp version 1 or 2 back in 93?94? , perhaps we should just define them
> with configure option --enable-gmpcompat ?
> I think you have to make it sl
On Tuesday 20 October 2009 17:44:38 Pierrick Gaudry wrote:
> Hi,
>
> For your information, these problems have been fixed in the development
> repos of gmp-ecm and mpfr respectively.
>
> What about keeping symbols for all obsolete functions, with a small
> wrapper (or the original function) so as
Hi,
For your information, these problems have been fixed in the development
repos of gmp-ecm and mpfr respectively.
What about keeping symbols for all obsolete functions, with a small
wrapper (or the original function) so as to be sure that you are still
compatible with old or not-yet-updated s
No issues with try testing on SkyNet after quite a few hours bashing
away on mpn_tdiv_q. I didn't test on menas or fulvia. I couldn't find
the C compiler on menas and got this when I tried to run try on
fulvia:
-bash-3.00$ ./try mpn_tdiv_q
ld.so.1: try: fatal: libgcc_s.so.1: open failed: No such
19 matches
Mail list logo
