On Thu, Sep 5, 2019 at 11:43 PM Victor Shoup <sh...@cs.nyu.edu> 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` there. This has already been explained, I think. We'd need to find out first whether this needs to be passed to the configure script. In particular as NTL provides no way for discovering whether it is built with pthreads or not. E.g. for my task it means to do half a page of ugly hard to write and maintain autoconf stuff just because you refuse to apply the patch I already provided and tested for you? We've been sending these dozens of emails back and force here for no good reason... > > 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 not any worse > than the > current situation. > > At a minimum, I can update NTL's documentation. > I could also modify the configure script so that this setting is the default. > Or I can try to do something "automagical"... > > I'd rather do this than patch libtool itself. > > > On Thursday, September 5, 2019 at 10:35:42 AM UTC-4, Antonio Rojas wrote: >> >> >> >> 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 https://trac.sagemath.org/ticket/28406, >>> that seems >>> to be what is "wrong". >> >> >> Do you seriously not see why this is wrong? This is a textbook case of >> underlinking. Your library is calling functions from the libpthread library, >> so it *must* link to it. This is not a matter of "conventions" or "choices", >> this is how dynamic linking works. If you refuse to acknowledge that this is >> a problem then there's certainly nothing else to discuss. >> >>> When I actually build a program, either in the build directory using NTL's >>> makefile with libtool, >>> or in another directory using a different makefile that uses g++, it works >>> fine. >> >> >> And we already have two programs that don't work: latte-integrale (al least >> the old version which I reported to you a year ago) and barvinok. And no, >> building those programs with -pthread is definitely not the solution: If a >> library A uses a function from library B and a program C uses a function >> from library A but nothing from library B then C does not have to and should >> not link to B: it's A's job to link to B. >> >>> So my understanding is that whenever you compile a multi-threaded program >>> you should pass -pthread to gcc. >> >> >> Correct. But you should *not* have to pass -pthread when you compile a >> single-threaded program and happens to use a multi-threaded library, which >> is the case here. > > -- > You received this message because you are subscribed to the Google Groups > "sage-devel" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to sage-devel+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/sage-devel/71bbcca2-89d0-4c97-b9fd-639cc695bee4%40googlegroups.com. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq3ebVK2hSXkc1oLg-Bq3SbqQkdmgX4DCiS4mimeHefffQ%40mail.gmail.com.
