Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
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 > 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 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
Re: [sage-devel] Re: error building barvinok (sage 8.9.beta8 + system NTL)
On Mon, 2 Sep 2019 at 23:24, Dima Pasechnik wrote: > On Tue, Sep 3, 2019 at 1:05 AM Victor Shoup 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. > In eclib, in configure.ac ( https://github.com/JohnCremona/eclib/blob/master/configure.ac) I have the line AX_PTHREAD but also put in some explicit fplags into the Makefile templates, e.g. https://github.com/JohnCremona/eclib/blob/master/libsrc/Makefile.am has the lines AM_CPPFLAGS = $(FLINT_CFLAGS) $(NTL_CFLAGS) $(PARI_CFLAGS) $(BOOST_CPPFLAGS) $(MPFP_SWITCH) $(PTHREAD_CFLAGS) AM_LDFLAGS = $(FLINT_LDFLAGS) $(NTL_LDFLAGS) $(PARI_LDFLAGS) $(LDFLAGS_BOOST) $(PTHREAD_CFLAGS) $(PTHREAD_LDFLAGS) LIBS= $(FLINT_LIBS) $(NTL_LIBS) $(PARI_LIBS) $(BOOST_LIBS) $(PTHREAD_LIBS) I would expect not to have to "manually" add these PTHREAD_* items if libtool worked as expected. It took a lot of experimentation to get something which worked, and I don't know if it is right, but it does work. I am *not* an expert on this! John > > > > > 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 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. >
