error building eclib with SageMath 8.9.beta7

[Vincent Delecroix]

Dear all,

I obtain an error while building eclib. The end of the log
says

/usr/bin/ld: avma: TLS definition in /lib/libpari.so section .tbss
mismatches non-TLS reference in .libs/parifact.o
/usr/bin/ld: /lib/libpari.so: error adding symbols: bad value
collect2: error: ld returned 1 exit status

But the pari should be the one coming from sage itself. See
the attached config.log.

Best
Vincent

[François Bissey]

First question. Is sage’s pari installed?

François

> --
> 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+...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/0c6c9eec-7c12-64b7-cf7b-aa2853e93419%40gmail.com.
> <config.log><eclib-20190226.log>

[Vincent Delecroix]

The install log says

Successfully installed pari-2.11.1.p2

And I confirm that gp is installed (in /opt/sage/local/bin/gp)
and working correctly.

Vincent

[Dima Pasechnik]

it seems that eclib tries to link against the system's libpari, even though it was meant to use Sage's libpari.

for a quick fix, either uninstall system pari, or uninstall Sage's pari, and rebuild.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/53ea0f93-e63f-d1cb-7d93-160d925cf945%40gmail.com.

[Vincent Delecroix]

I would be happier with a long term fix (and I don't want to uninstall
my system pari as many other packages depend on it).

[Dima Pasechnik]

I suppose it is a eclib bug, which does not do linking in a "safe" way, but relies on ld finding a libpari around the system in some chaotic way...

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a844f4fe-cf4f-e96d-be57-d782fbff1910%40gmail.com.

[Dima Pasechnik]

do you need to hack libpari, or you'd be happy with one from the system?

On Sun, 25 Aug 2019 15:10 Vincent Delecroix, <20100.d...@gmail.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/a844f4fe-cf4f-e96d-be57-d782fbff1910%40gmail.com.

[Vincent Delecroix]

I would be happy with the one from the system. But apparently, the one
shipped by archlinux is not good enough (have a look at the config.log
that I sent with my first e-mail).

[Vincent Delecroix]

It becomes weird:

I untared eclib than ran

$ sage -sh
$ ./configure --with-pari=/opt/sage/local --with-boost="no"
--disable--allprogs
$ make

and everything went fine

[John Cremona]

I think Vincent's solution is the correct one. If the sage install script was like that it would only look where it is told and not in a standatd place such as /usr/local.  This should be done.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2b0e429a-737c-459b-6952-c1bdf732a69c%40gmail.com.

[François Bissey]

What would be interesting is the config.log for the eclib compile that goes wrong.
And then I may have a few interesting commands to test further if needs be.
But extra configuration parameters in eclib’s spkg-install may well do the trick.

François

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K7ZhV_%2BL-ALovpn-q8b5ayD4TE07%2BkU-6Qi53XKDWnm6A%40mail.gmail.com.

[Dima Pasechnik]

well, what goes wrong in the end is visible in eclib-20190226.log
specifically, in the failing ld call at the end there is

" -L/lib -L/opt/sage/local/lib -lflint -lntl -lpari "

which results in libpari picked up from /lib
I suppose /lib gets in the way just because Flint and NTL are coming
from the system, and the corresponding libs are in /lib

If -L/lib is dropped there then it should work IMHO.

I don't quite see why -L/lib gets there at all, though...

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/F8D5D2B1-0BBB-4119-9965-ED3CF59EE945%40gmail.com.

[François Bissey]

Good catch. Yes, your explanation makes complete sense. Which means we have
to make sure the right library path for pari is included in front of
-lpari.

Further examination may be required to figure out the presence of `-L/lib`.
First it would be interesting to see if it appears in other packages that don’t
use system package. If it does we are global variable pollution.
If not it’s probably just something in eclib.

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAAWYfq0zGLfmh%2B5p4foAfSd_2SPTd-vY_V_QeO0PYfS_ZXGKeA%40mail.gmail.com.

[Dima Pasechnik]

On Sun, 25 Aug 2019 18:42 John Cremona, <john.c...@gmail.com> wrote:

I think Vincent's solution is the correct one.

I guess I know how this made difference to running ./sage -i eclib. - but it's not what you think.

Namely, in this case --with-pari option got processed before NTL and Flint, and so the order of -L options passed to the linker by eclib

has changed (perhaps the fatal "-L/lib" didn't get passed at all in such a case)

If the sage install script was like that it would only look where it is told and not in a standatd place such as /usr/local.  This should be done.

Of course Sage's ./configure looks for libraries in default locations, unless specified.

The problem is eclib plays fast and loose with locations of external libs NTL, Flint, and Pari, and basically, unless they are all in the same place,

mutiple copies of these in different locations might spell trouble.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/CAD0p0K7ZhV_%2BL-ALovpn-q8b5ayD4TE07%2BkU-6Qi53XKDWnm6A%40mail.gmail.com.

[Dima Pasechnik]

On Sun, Aug 25, 2019 at 11:58 PM François Bissey <frp.b...@gmail.com> wrote:
>
> Good catch. Yes, your explanation makes complete sense. Which means we have
> to make sure the right library path for pari is included in front of
> -lpari.
>
> Further examination may be required to figure out the presence of `-L/lib`.
> First it would be interesting to see if it appears in other packages that don’t
> use system package. If it does we are global variable pollution.
> If not it’s probably just something in eclib.

It's a subtle bug I introduced in spkg-config of eclib, which is due
to non-uniformity of
values to be passed to ./configure of eclib via --with-FOO=, for FOO
in ntl, pari, flint.

Namely, --with-flint="" results in -L/lib getting into FLINT_LDFLAGS,
whereas --with-flint=yes
does not do this.

By non-uniformity I mean that configure.ac of ecl has

case "$with_pari" in
""|yes)

and

case "$with_ntl" in
""|yes)

whereas for flint it has
does different things for "" and for yes.
For withval=="" it does add FLINT_LDFLAGS="-L$withval/lib", but
for withval==yes it does not touch FLINT_LDFLAGS=

(Naturally, if one sets up such a pitfall, sooner or later it had to work ;-))

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/4CDEDCD3-6CDB-412A-93A9-5C5F823067EE%40gmail.com.

[Dima Pasechnik]

I've opened https://trac.sagemath.org/ticket/28401 to deal with this.
Vincent,
could you please try changing in spkg-install of eclib the line

--with-flint=$SAGE_FLINT_PREFIX \

to

--with-flint \

and see if this allows you to install eclib.
Sorry for trouble,

Dima

Could you post your src/bin/sage-env-config, as well as config.log
from the directory of failed build of eclib?
This should shed light on what exactly are the options passed to
eclib's ./configure
Thanks,
Dima


On Sun, Aug 25, 2019 at 6:16 PM Vincent Delecroix

> To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/2b0e429a-737c-459b-6952-c1bdf732a69c%40gmail.com.

[Vincent Delecroix]

Le 26/08/2019 à 00:08, Dima Pasechnik a écrit :
> Vincent,
> could you please try changing in spkg-install of eclib the line
>
> --with-flint=$SAGE_FLINT_PREFIX \
>
> to
>
> --with-flint \
>
> and see if this allows you to install eclib.

This worked! Thank you for the fix!

Vincent

[Dima Pasechnik]

On Sun, 25 Aug 2019 17:53 Vincent Delecroix, <20100.d...@gmail.com> wrote:

I would be happy with the one from the system. But apparently, the one
shipped by archlinux is not good enough (have a look at the config.log
that I sent with my first e-mail).

thanks, this was useful. It helped to find the bug I just fixed on #28405 in particular.

Do you have all the pari packages available on Arch installed?

We ought to ask Arch people to provide the missing ones.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/376a5eb8-3bc1-9cd2-9ed5-7328d88ed3e0%40gmail.com.

[Vincent Delecroix]

Le 26/08/2019 à 15:58, Dima Pasechnik a écrit :
> On Sun, 25 Aug 2019 17:53 Vincent Delecroix, <20100.d...@gmail.com>
> wrote:
>
>> I would be happy with the one from the system. But apparently, the one
>> shipped by archlinux is not good enough (have a look at the config.log
>> that I sent with my first e-mail).
>>
>
> thanks, this was useful. It helped to find the bug I just fixed on #28405
> in particular.
>
> Do you have all the pari packages available on Arch installed?
>
> We ought to ask Arch people to provide the missing ones.
>

This is weird because I have Sage from the system available (it is
version 8.8). Here is the list of relevant pari packages that
are installed

community/pari 2.11.2-1 [installed]
community/pari-galdata 20080411-2 [installed]
community/pari-seadata-small 20090618-2 [installed]
community/python2-cypari2 2.1.1-1 [installed]

It might be the case that they are somehow buggy.

Vincent

[E. Madison Bray]

Configure issues aside, the main reason for the original problem is that the system's PARI is built with multi-threading support, whereas in Sage we build PARI (and by extension its dependencies) without multi-threading support.

Perhaps we should change that. The major known issue with using multi-threaded PARI with Sage is that it breaks the documentation build. I have a ticket that works around that though, needing review: https://trac.sagemath.org/ticket/28356

More generally, with a multi-threaded PARI, it is not safe to use Sage itself in multi-threaded code. This is annoying and should be fixed, but is also a broader issue.... 

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/067eb3eb-578a-3b04-0522-df6b855a0f1f%40gmail.com.

[Dima Pasechnik]

well, we check for more pari packages than that. Basically for what is in Debian.

This is to make sure that optional pari packages are there too; as pari doesn't have any way to install them in "user space", unlike, say, GAP.

--
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+...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/067eb3eb-578a-3b04-0522-df6b855a0f1f%40gmail.com.

[Dima Pasechnik]

By the way, it appears that Arch has all the PARI packages needed, at
https://aur.archlinux.org/packages/?K=pari-

so they ought to be installed to use the system PARI on Arch.