On Tue, Sep 3, 2019 at 2:21 PM Victor Shoup <sh...@cs.nyu.edu> wrote: > > So, I'm willing to patch libtool using your patch, as you suggest. > Just to confirm: I just replace ltmain.sh in libtool-origin with the patched > version, > and that's it.
yes. > > I have another question... > I've installed NTL on Linux with libtool, and I've never had a problem. > 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++). > As such, I'm still kind of confused as to what the problem is. 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." > > Related to that, from what I read, -lpthread is less standard than -pthread: > again, the latter is supposed to add the necessary linker flags. > Thus, I'm still a bit hesitant to do this. well, see above. As you elect to explictly call libtool, you have no choice but to use "-lpthread" Dima > > I guess I still don't entirely understand the model. > > > On Monday, September 2, 2019 at 6:24:00 PM UTC-4, Dima Pasechnik wrote: >> >> On Tue, Sep 3, 2019 at 1:05 AM Victor Shoup <sh...@cs.nyu.edu> wrote: >> > >> > OK. So this is really a bug in libtool. >> it's a feature :-) >> It's not hard to explicitly pass extra libraries to link to libtool, >> and thus it's still like this. >> >> > It seems to me that even if I used autotools for everything, the same >> > problem would persist >> > without a patch to ltmain.sh. >> > >> > Is that right? >> > >> no, if you use autotools, you'd just add a couple of macros to deal with >> threads to configure.ac, and the rest will be done correctly, >> as autotools are aware of this bug/feature of libtool and know >> what to do. >> >> > >> > On Monday, September 2, 2019 at 4:42:44 PM UTC-4, Dima Pasechnik wrote: >> >> >> >> On Mon, Sep 2, 2019 at 11:37 PM Victor Shoup <sh...@cs.nyu.edu> wrote: >> >> > >> >> > A clarification and a question... >> >> > >> >> > NTL's config system does not use a pre-built ibtool script. Rather, it >> >> > builds a customized libtool by running a configure script on the host >> >> > machine, so it should, in principle, be using a libtool script that is >> >> > properly configured for the host machine. >> >> > >> >> > The configure script itself was built on a linux machine with >> >> > up-to-date autotools using the following configure.ac file: >> >> > >> >> > AC_INIT(ntl-libtool, 1.0) >> >> > AM_INIT_AUTOMAKE([foreign]) >> >> > AC_CONFIG_FILES([Makefile]) >> >> > LT_INIT >> >> > AC_PROG_CXX >> >> > AC_PROG_CC >> >> > AC_PROG_LIBTOOL >> >> > AC_OUTPUT >> >> > >> >> > I don't remember where I got this...but it was from somebody who seemed >> >> > to know what they were talking about. >> >> > >> >> > Maybe the logic of this configure.ac file is not right? >> >> > Any thoughts on this? >> >> >> >> it looks OK, and the libtool you get will ignore -pthread option for >> >> gcc/g++, >> >> (as this is by design), unless you apply the patch I posted earlier before >> >> buiding it. >> >> >> >> >> >> > >> >> > >> >> > >> >> > On Wednesday, August 28, 2019 at 9:55:38 AM UTC-4, vdelecroix wrote: >> >> >> >> >> >> Victor, as far as I understand the main configuration script of ntl >> >> >> is the perl DoConfig script. It has nothing to do with libtool. libtool >> >> >> is robust if you let it handle the configuration. It will not try to >> >> >> fix a given one. >> >> >> >> >> >> In a libtool configure.ac script you would just have a directive >> >> >> AC_CHECK_LIB for pthread. >> >> >> >> >> >> In short, I would suggest >> >> >> >> >> >> 3) Replace DoConfig by a configure.ac script >> >> >> >> >> >> Vincent >> >> >> >> >> >> Le 28/08/2019 à 15:15, Victor Shoup a écrit : >> >> >> > Thanks. I guess what I'm asking for is a solution. From what you >> >> >> > say here, >> >> >> > and what is said in the links, the problem seems to be a bug in >> >> >> > libtool, >> >> >> > not NTL. So a solution would be, either: >> >> >> > 1) a patch other type of libtool workaround, or >> >> >> > 2) an alternative to libtool. >> >> >> > I though the whole point of libtool was to take care of all this >> >> >> > nonsense, >> >> >> > and if it's not doing that, then >> >> >> > it seems kind of pointless. >> >> >> > >> >> >> > On Tuesday, August 27, 2019 at 1:42:51 PM UTC-4, Antonio Rojas wrote: >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> El martes, 27 de agosto de 2019, 16:25:12 (UTC+2), Victor Shoup >> >> >> >> escribió: >> >> >> >>> >> >> >> >>> I reviewed some comments which mentioned a problem with ntl and >> >> >> >>> threads. >> >> >> >>> I’m happy to fix that, but I don’t think I understand what the >> >> >> >>> issue is. >> >> >> >>> Can anyone explain? Thanks. >> >> >> >> >> >> >> >> >> >> >> >> Hi Victor, >> >> >> >> IIRC I reported this to you about a year ago. The problem is that >> >> >> >> you are >> >> >> >> using libtool as a build command, which calls the compiler with the >> >> >> >> -nostdlib flag, which in turn overrides the -pthread flag, so the >> >> >> >> binaries >> >> >> >> end up not being linked to libpthread. See eg. [1][2] for more info. >> >> >> >> >> >> >> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=661333 >> >> >> >> [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25460 >> >> >> >> >> >> >> > >> >> > >> >> > -- >> >> > 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/30264407-95c4-4057-a7a8-5dc0ea8b6437%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-...@googlegroups.com. >> > To view this discussion on the web visit >> > https://groups.google.com/d/msgid/sage-devel/77278251-5ad4-42a2-a9f0-c0bf322fb972%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/94761df3-02c7-4304-b218-81607c13aa21%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/CAAWYfq0-juvKv7%3DYYUi%2BqZhDR4mYczc_BJat4H%2BTR5%2B9s4qkag%40mail.gmail.com.
