On Thu, 5 Sep 2019 14:51 Victor Shoup, wrote:
> We seem to be talking past each other.
>
> Here is my experience.
> My OS: Red Hat Enterprise Linux Server 7.7 (Maipo)
> My compiler: gcc 4.8.5 (yes, it's old!)
>
> Here is how I built NTL:
>
> $ ./configure SHARED=on PREFIX= /home/gid-shoupv/sw
>
El jueves, 5 de septiembre de 2019, 15:51:34 (UTC+2), Victor Shoup escribió:
>
> We seem to be talking past each other.
>
Unfortunately it seems so.
It is also true that when I run ldd on libntl.so, I do not see anything
> related to pthread.
> From the comments I'm reading in
We seem to be talking past each other.
Here is my experience.
My OS: Red Hat Enterprise Linux Server 7.7 (Maipo)
My compiler: gcc 4.8.5 (yes, it's old!)
Here is how I built NTL:
$ ./configure SHARED=on PREFIX= /home/gid-shoupv/sw
$ make
$ make install
Then, in another directory, where I am
On Thu, Sep 5, 2019 at 6:29 PM David Guichard
wrote:
> When is a linear system consistent?
>
> This isn't helpful:
>
> a,b,c=var('a b c')
> A=matrix([[-4,5,9,a],[1, -2, 1, b],[-2,4,-2,c]])
> A.echelon_form()
> A.rref()
>
> [1 0 -23/3 0]
> [0 1 -13/3 0]
> [0 0
So NTL's configure script already provides a work-around.
Just pass LIBTOOL_LINKER_FLAGS=-lpthread to NTL's configure script,
and the problem goes away.
To the extent that NTL's configure interface is already a bit non-standard,
asking
package managers to do this is probably OK...at least, it's
I'm really just trying to understand what's going on.
So there is a good reason: my own education...although maybe you don't like
that reason :-)
In fact, I just tested my proposal, and it indeed doesn't work.
I am convinced that the patch is the way to go.
On Thursday, September 5, 2019 at
I updated my PGFFT (Pretty Good FFT) library.
Details here: https://www.shoup.net/PGFFT/
It is now almost as fast or faster than FFTW on transforms up to 100K or so,
at least on AVX or AVX2 machines. I've posted some more timings.
If anyone is curious, the only reason I did this is that for
On Thu, Sep 5, 2019 at 11:43 PM Victor Shoup wrote:
>
> So NTL's configure script already provides a work-around.
> Just pass LIBTOOL_LINKER_FLAGS=-lpthread to NTL's configure script,
> and the problem goes away.
No, it won'd magically go away, as one cannot blindly stick in this `-lpthread`
Sigh.
"...a textbook case of underlinking..."
I guess I never read that textbook.
I guess I just didn't know there was a whole community of people and
projects who don't
like putting -pthread in their makefiles.
I feel like this is becoming a religious war.
If it will keep the peace, I will
On Thu, Sep 5, 2019 at 9:48 PM Victor Shoup wrote:
>
> Sigh.
> "...a textbook case of underlinking..."
> I guess I never read that textbook.
> I guess I just didn't know there was a whole community of people and projects
> who don't
> like putting -pthread in their makefiles.
>
> I feel like
When is a linear system consistent?
This isn't helpful:
a,b,c=var('a b c')
A=matrix([[-4,5,9,a],[1, -2, 1, b],[-2,4,-2,c]])
A.echelon_form()
A.rref()
[1 0 -23/3 0]
[0 1 -13/3 0]
[0 0 0 1]
[1 0 -23/3 0]
[0 1 -13/3 0]
[0 0
On Thu, 5 Sep 2019 at 05:07, Victor Shoup wrote:
> Please see comments/questions below...
>
> On Wednesday, September 4, 2019 at 6:04:42 AM UTC-4, Dima Pasechnik wrote:
>>
>> On Tue, Sep 3, 2019 at 2:21 PM Victor Shoup wrote:
>> >
>>
>> > When I compile a program that uses NTL, I always pass
El jueves, 5 de septiembre de 2019, 6:07:13 (UTC+2), Victor Shoup escribió:
> So, based on that comment, it seems that there is no problem if you link
> with g++
> rather than libtool. But who or what uses libtool to link?
> I would never have thought of doing that, as I thought libtool was
13 matches
Mail list logo
