On Sunday 15 November 2009 02:53:57 William Stein wrote:
> On Sat, Nov 14, 2009 at 6:48 PM, Jason Moxham
wrote:
> > On Sunday 15 November 2009 02:24:47 William Stein wrote:
> >> On Sat, Nov 14, 2009 at 6:17 PM, Jason Moxham
> >>
> >
> > wrote:
> >> > Of course , that is the error
> >> > LD_LIBR
On Sat, Nov 14, 2009 at 6:48 PM, Jason Moxham wrote:
>
> On Sunday 15 November 2009 02:24:47 William Stein wrote:
>> On Sat, Nov 14, 2009 at 6:17 PM, Jason Moxham
> wrote:
>> > Of course , that is the error
>> > LD_LIBRARY_PATH sets the path for executables so there is no need for it
>> > to be
On Sunday 15 November 2009 02:24:47 William Stein wrote:
> On Sat, Nov 14, 2009 at 6:17 PM, Jason Moxham
wrote:
> > Of course , that is the error
> > LD_LIBRARY_PATH sets the path for executables so there is no need for it
> > to be set when building pari (just when running it) so the only thing
On Sat, Nov 14, 2009 at 6:17 PM, Jason Moxham wrote:
>
> Of course , that is the error
> LD_LIBRARY_PATH sets the path for executables so there is no need for it to be
> set when building pari (just when running it) so the only thing that is USING
> libgmp is gcc which doesn't like it .
This me
Of course , that is the error
LD_LIBRARY_PATH sets the path for executables so there is no need for it to be
set when building pari (just when running it) so the only thing that is USING
libgmp is gcc which doesn't like it .
On Sunday 15 November 2009 02:06:25 Jason Moxham wrote:
> this is w
this is with mpir-1.2 ,and I think we have only start to remove them in 1.3
I mean pari builds fine with our fat enabled mpir , but only if
LD_LIBRARY_PATH does NOT point to our libmpir
LD_LIBRARY_PATH is not used until linking time ? so it should have no effect on
the compile .
If gcc is usi
Heh! I don't suppose gcc would be using old deprecated functions which
we've removed. :-)
Bill.
2009/11/15 Bill Hart :
> That seems like a likely possibility, in which case one presumes there
> is a symbol which GMP provides and we don't, or at least our interface
> is different.
>
> I think gcc
That seems like a likely possibility, in which case one presumes there
is a symbol which GMP provides and we don't, or at least our interface
is different.
I think gcc only uses GMP for constant folding though, and the line in
question didn't involve any constants did it?
I wonder how one even d
export
LD_LIBRARY_PATH=/tmp/jason/sage-4.2.1/local/lib/R/lib:/tmp/jason/sage-4.2.1/local/lib/openmpi:/tmp/jason/sage-4.2.1/local/lib/:
like the sage shell does and then we get the same error
So I deleted all files in .../local/lib/ except libgmp*
and exported
LD_LIBRARY_PATH=/tmp/jason/sage-
2009/11/15 William Stein
>
> On Sat, Nov 14, 2009 at 4:31 PM, gerrob wrote:
> >
> > I've uploaded a new code on google group. It is using remainder tree
> > to speedup the sieving, and now it is sieving up to about log2(n)^2.
> > It means a speedup by a factor of two for large "random" input (he
On Sat, Nov 14, 2009 at 4:31 PM, gerrob wrote:
>
> I've uploaded a new code on google group. It is using remainder tree
> to speedup the sieving, and now it is sieving up to about log2(n)^2.
> It means a speedup by a factor of two for large "random" input (here
> random means that nextprime(n) is
I've uploaded a new code on google group. It is using remainder tree
to speedup the sieving, and now it is sieving up to about log2(n)^2.
It means a speedup by a factor of two for large "random" input (here
random means that nextprime(n) isn't very close to n). For totally
random inputs it is fast
It appears to be the actual environment that sage provides in its "sage
subshell"
ie
Building pari in the sage shell
sage subshell$ ./Configure --graphic=none
--prefix=/tmp/jason/sage-4.2.1/local
--with-readline=/tmp/jason/sage-4.2.1/local --with-
gmp=/tmp/jason/sage-4.2.1/local --kernel=
Was the option -O1 passed to gcc in all instances where the problem occurred?
I have heard of instances where -O1 will cause macro errors which
cause the compiler to shut down. When a higher optimisation level is
used the macro which causes the crash in gcc is optimised away.
If that turns out t
On Sat, Nov 14, 2009 at 12:05 AM, Jason Moxham
wrote:
>
> Hi
>
> I thought I would give it a try , but I cant login to debian32 , doesn't like
> my password , although boxen and fedora32 are OK ??
> I thought the passwords were all the same for the virtual machines.
No. I've added your login in
Hi
I thought I would give it a try , but I cant login to debian32 , doesn't like
my password , although boxen and fedora32 are OK ??
I thought the passwords were all the same for the virtual machines.
I havent managed to reproduce any error on some other 32bit machines but
nothing was exactly
16 matches
Mail list logo
