On Thu, 5 Sep 2019 14:51 Victor Shoup, <sh...@cs.nyu.edu> 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 > $ 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. >
No, I am compiling a program that uses NTL, that's all. It need not use threads by itself. Why must I bother about -pthread? And if NTL is using threads, but not linked to pthread library (the current NTL setup), then my program will not link. This won't happen with a patch I proposed to apply. > 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> 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. >>> 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 > <https://groups.google.com/d/msgid/sage-devel/9fe439d2-c87c-44e1-aa06-f2b856ff6bec%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/CAAWYfq33ruMRCT12TYOqJ0DREfGAHD8-y52kYqta8br79%3DToag%40mail.gmail.com.
