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 using NTL as a library in another program: $ g++ -std=c++11 -pthread -g -O2 -DFHE_THREAD -o Test_thinboot_x Test_thinboot.cpp fhe.a -lntl -lgmp -lm Then, ldd says: $ ldd Test_thinboot_x linux-vdso.so.1 => (0x00007ffef18a0000) libntl.so.40 => /home/gid-shoupv/sw/lib/libntl.so.40 (0x00007f51044d4000) libgmp.so.10 => /usr/local/lib/libgmp.so.10 (0x00007f510425e000) libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f5103f45000) libm.so.6 => /lib64/libm.so.6 (0x00007f5103c43000) libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f5103a2c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f5103810000) libc.so.6 => /lib64/libc.so.6 (0x00007f5103442000) /lib64/ld-linux-x86-64.so.2 (0x00007f5104978000) This is what I mean by "everything just works". Also, when I build NTL with SHARED=on, if I build test programs in the build directory using the makefile there, then, for example, I get: $ make ThreadTest ./libtool-build/libtool --tag=CXX --mode=link g++ -I../include -I. -g -O2 -std=c++11 -pthread -march=native -o ThreadTest ThreadTest.cpp libntl.la #LSHAR libtool: link: g++ -I../include -I. -g -O2 -std=c++11 -pthread -march=native -o .libs/ThreadTest ThreadTest.cpp ./.libs/libntl.so -lgmp -pthread -Wl,-rpath -Wl,/home/gid-shoupv/sw/lib This works just fine: the program ThreadTest compiles, links, and runs just fine, but for some reason ldd says "not a dynamic executable". I'm not sure what's up with that. A quick google search indicates that ldd can sometimes be buggy in this way. This may not mean anything regarding the issues we are discussing. Now, Antonio posted some output that showed that when libtool is used to create the library, it uses g++ with -nostdlib. Indeed, that is what I see as well. But from where I'm sitting, this is not a problem. 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. 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 <https://www.google.com/url?q=https%3A%2F%2Ftrac.sagemath.org%2Fticket%2F28406&sa=D&sntz=1&usg=AFQjCNGrwfVRTUQ4wc8gDByCwBimhxvMtA>, that seems to be what is "wrong". Looking closer at the comments there, I see that the command that does not as expected is this: $ gcc -o conftest -g -O2 -L/opt/sage/local/lib -Wl,-rpath,/opt/sage/local/lib conftest.c -lntl -lgmp That this should work is contrary to my understanding of the "-pthread" flag. man gcc says: -pthread Adds support for multithreading with the pthreads library. This option sets flags for both the preprocessor and linker. So my understanding is that whenever you compile a multi-threaded program you should pass -pthread to gcc. To me, this has nothing to do with libtool. Maybe, just maybe, the real "issue" is this: some build systems do not pass "-pthread" to gcc, but rather, they depend on libntl.so to contain a reference to libpthreads.so. If that is true, then I guess this "issue" is really just one of what the proper conventions are for who is responsible to passing the right flags to gcc. There is never going to be a perfect solution to this. For example, on some compiles, you have to pass "-std=c++11" to gcc in order to compile a program that includes NTL header files. That's just one more thing to keep straight. So I'm not convinced that patching libtool in NTL is the right thing to do. Before I fix anything, I'd like to know what it is I'm actually fixing. But probably if your build system needs t follow specific conventions not supported by libtool, then you can build NTL using a custom libtool that supports your conventions. That's probably where this ends. On Thursday, September 5, 2019 at 2:48:58 AM UTC-4, Dima Pasechnik wrote: > > > > On Thu, 5 Sep 2019 at 05:07, Victor Shoup <sh...@cs.nyu.edu <javascript:>> > 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 <sh...@cs.nyu.edu> wrote: >>> > >>> >>> > When I compile a program that uses NTL, I always pass -pthread to g++. >>> > Doesn't that automatically cause the necessary pthread-specific >>> library to be linked in? >>> >>> it does, if you don't use libtool to link (and typically one would >>> link an executable with >>> an explicit call to g++). >>> >> >> 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 a tool >> for creating libraries, not linking programs. >> > > Linking a program with g++ is easy, linking a shared library with g++ is > hard. > This is why libtool was invented in the 1st place, to help the latter. > > >> >>> the problem is that libtool strips away the -pthread flag. >>> As long as you don't use it, there is no problem. See >>> >>> https://www.gnu.org/software/libtool/manual/libtool.html#Stripped-link-flags >>> >>> "13.1 Why does libtool strip link flags when creating a library? >>> >>> When creating a shared library, but not when compiling or creating a >>> program, libtool drops some flags from the command line provided by >>> the user. This is done because flags unknown to libtool may interfere >>> with library creation or require additional support from libtool, and >>> because omitting flags is usually the conservative choice for a >>> successful build." >>> >>> >> This is confusing. If you use libtool to link, then the above quote would >> suggest that >> in that context, libtool should not strip away any linker flags. >> But you seem to be saying that it does. >> > > Sorry, I was not careful in my last message. indeed, you are right, > libtool only drops flag while making a shared library, but not while making > a program. > > >> So...I am still confused. >> >> Regarding the libtool that I am bundling with NTL: >> 1) is it stripping some flags during compilation that should not be >> stripped? >> 2) is it stripping some flags during linking that should not be stripped? >> > > during linking a dynamic library libtools strips flags it does not know > about. > (and only in this case). > With the patch I posted, it will “know” about the -pthread flag and do the > right thing. > > >> Again, when I build and install a shared NTL on a linux system, >> everything works fine. >> So I'm not even sure what the problem is: >> > >> I can build it and link to it in the build directory using libtool. >> I can install it using libtool somewhere else and later link to it using >> g++. >> What am I missing?!? >> > > libtool handles linking dylibs and programs differently, it honours flags > in the latter case, but not in the former case. > > Dima > >> -- >> 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/15c39061-e49d-4c6b-951b-6763aaea5dd0%40googlegroups.com >> >> <https://groups.google.com/d/msgid/sage-devel/15c39061-e49d-4c6b-951b-6763aaea5dd0%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- 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/9fe439d2-c87c-44e1-aa06-f2b856ff6bec%40googlegroups.com.
