I spent a couple of hours experimenting with your patch as well as with the solution of just changing NTL's makefile to stick -lpthread in the invocation of libtool:
$(LIBTOOL) --tag=CXX --mode=link $(LINK) $(LIBTOOL_LINK_FLAGS) -o libntl.la $(OBJ:.o=.lo) $(GMP_OPT_LIBDIR) $(GMP_OPT_LIB) $(GF2X_OPT_LIBDIR) $(GF2X_OPT_LIB) $(LDLIBS) -lpthread -rpath $(LIBDIR) -version-info `cat VERSION_INFO` Examining the make output, they both yield essentially the same result. Your libtool patch ends up putting -lpthread in basically the same place. I have tested both approaches in linking another program (without specifying -pthread or -lpthread) and they both worked fine. I wasted a lot of time investigating why both approaches fail when linking a program that uses a static library that depends on NTLI got the error: /usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line I never really solved that puzzle. Instead of patching libtool (which is harder for me to maintain in the long run), I will just modify NTL's configure script to do the same thing (at least that is something under my direct control). I will modify NTL's config to define a makefile variable PTHREAD_LIB which will be set to -lpthread and passed to libtool when linking, if that seems like the right thing to do. The user running config can manually override PTHREAD_LIB if need be. This was a learning experience. I'm very used to linking static libraries, where you must explicitly list all libraries on the command line. Now dynamic libs come along and offer the feature of listing their own dependencies, which is a feature that build systems have apparently come to rely upon. That was news to me. Another bit of information: the only reason NTL relies on libpthread at all is because it is working around buggy implementations of the C++11 "thread_local" feature. It has been absolutely shocking to me that these bugs have been around for several years, and I'm not sure if they are still around or not...I trust my simple pthread implementation more than the buggy gcc/clang implementations. On Thursday, September 5, 2019 at 6:57:36 PM UTC-4, Dima Pasechnik wrote: > > On Thu, Sep 5, 2019 at 11:43 PM Victor Shoup <sh...@cs.nyu.edu > <javascript:>> 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-...@googlegroups.com <javascript:>. > > 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/5d7683bd-dfa9-48de-9a93-3c566dab8bbb%40googlegroups.com.
