Undefined symbol in libgap on archlinux

[sagetrac-aloys-dufour]

On Archlinux (updated on 27-03-2019), SageMath version 8.6, Release Date: 2019-01-15 ;

sage: Oh = cartesian_product([SymmetricGroup(4),SymmetricGroup(2)])
sage: Oh.cardinality()
#W dlopen() error: /usr/lib/gap/pkg/io-4.5.4/bin/x86_64-pc-linux-gnu-default64/io.so: undefined symbol: ModInt
Error, module '/usr/lib/gap/pkg/io-4.5.4/bin/x86_64-pc-linux-gnu-default64/io.so' not found
Error, was not in any namespace
Syntax warning: Unbound global variable in /usr/lib/gap/lib/init.g:803
    ColorPrompt( UserPreference( "UseColorPrompt" ) );
               ^
Error, SetGasmanMessageStatus: function is not yet defined
/usr/lib/python2.7/site-packages/sage/interfaces/gap.py:646: UserWarning: this should never happen
  warnings.warn("this should never happen")

CC: @nthiery @embray

Component: interfaces

Issue created by migration from https://trac.sagemath.org/ticket/27372

[nthiery]

comment:2

Note: I was sitting next to Aloys machine; deleting the libgap workspace did not help.

[nthiery]

comment:3

Potential cause: dynamic modules are not yet well supported in libgap, right?
It seems Arch is packaging it nevertheless, and it gets automatically loaded in this case.

See #27218

[kiwifb]

comment:4

Amusing, I should try in sage-on-gentoo. I packaged all that but I haven't done a real live test of installing it.

[embray]

comment:5

Replying to @nthiery:

Potential cause: dynamic modules are not yet well supported in libgap, right?
It seems Arch is packaging it nevertheless, and it gets automatically loaded in this case.

See #27218

That is correct. This is fixed by #26930, so I would propose closing this as a duplicate, do you agree?

The fact is that without this fix, if some GAP packages are being loaded by default that in turn cause a shared module to be loaded it will fail.

[kiwifb]

comment:7

I had noticed that basic building in sage-on-gentoo meant that io.so had missing symbols but I thought they would provided by the executable loading it (that's totally allowed). For my arch colleagues, just LIBS=-lgap to the configure invocation and the problem is fixed.

[embray]

comment:8

Replying to @kiwifb:

I had noticed that basic building in sage-on-gentoo meant that io.so had missing symbols but I thought they would provided by the executable loading it (that's totally allowed). For my arch colleagues, just LIBS=-lgap to the configure invocation and the problem is fixed.

Yep. In the future all compiled GAP packages should link with libgap. Currently they don't, because until recently there was no libgap. And for the case of using GAP directly it isn't necessary because the gap executable does not dynamically link with libgap either--it is all statically linked, so loading compiled packages from the gap executable works, whereas loading them from libgap does not, necessarily, if libgap itself was loaded with lazy symbol resolution as is the case when loading it as a result of importing a Python module :/

[nthiery]

comment:9

This is fixed by #26930, so I would propose closing this as a duplicate, do you agree?

I would tend to wait for the fix to have percolated down to arch-linux to make sure everything is fine there (despite potential specific build idiosyncrasies). But otherwise, yes!

Thanks for your answer and all the quick progress.

[antonio-rojas]

comment:10

Linking all binary packages to libgap fixes this particular issue. However, this uncovers another problem: now I'm getting

/usr/lib/python2.7/site-packages/sage/interfaces/gap.py:648: UserWarning: this should never happen
  warnings.warn("this should never happen")

This line in gap.py corresponds to the error code 13: GAP is trying to send a Window command, which points to the xgap package.
I added some debug to figure out why the xgap package was being loaded and, to my surprise, I found out that Sage is trying to load every single GAP package installed on the system. Is that really intentional?

[antonio-rojas]

comment:11

Answering to myself: yes, this seems to be intentional

https://github.com/sagemath/sage-prod/blob/master/src/sage/interfaces/gap.py#L1581

So xgap should definitely be blacklisted here.

[antonio-rojas]

comment:12

Actually, the problem is not that it tries to load xgap: that seems to be dealt with in SAGE_EXTCODE/gap/sage.g. The problem is with packages that have xgap in SuggestedPackages, namely sonata and cryst: apparently the sage.g blacklist doesn't work in that case and they still try to load xgap.

I've worked around this downstream by removing xgap from SuggestedPackages in sonata and cryst for now, but this should be fixed in sage itself so that it doesn't try to load xgap under any circumstances.

[embray]

comment:13

I'm not sure if that can be fixed in Sage without some mechanism from upstream to make it easier to completely prevent a package from being loaded.

Also, the problem with xgap only impacts the pexpect interface to GAP. There are some tickets elsewhere about reducing, and ultimately eliminating dependence on that in the core Sage library.

[embray]

comment:14

Perhaps, also, the pexpect interface could be improved somewhat to actually "speak" the xgap window manager protocol and provide some dummy responses from the "window manager" when it asks for them =_=

[mkoeppe]

comment:15

Let's close it as outdated