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.
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? As such, I'm still kind of confused as to what the problem is. 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. 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 > <javascript:>> 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 <javascript:>. > > 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.
