On Sat, Sep 7, 2019 at 4:28 AM Victor Shoup <sh...@cs.nyu.edu> wrote: > > 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.
anything that provides a correctly linked NTL (i.e. no underlinking, no overlinking - do not link in -lpthread if it's not used) would be fine. Needless to say, unconditionally putting -lpthread there is not what my patch does, so it won't lead to overlinking. Your alternative fix would need to only add -lpthread if NTL is built with multi-threads on. > > 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. this sort of error usually comes up due to incorrect ordering of -l<...> options (and/or object files), i.e. -lA -lB foo.o might give an error, and to fix it you might need to re-order foo.o -lB -lA or, in case of circular dependencies, one might even need foo.o -lB -lA -lB > > > 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> 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. >> > 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. -- 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/CAAWYfq3n2WMWi8z8pGD_DQ7fRJUyaG4JRM-rAKoJz7rBMBiwnQ%40mail.gmail.com.
