Opened 19 months ago

Last modified 19 months ago

#27372 needs_review defect

Undefined symbol in libgap on archlinux

Reported by: aloys.dufour Owned by:
Priority: major Milestone: sage-duplicate/invalid/wontfix
Component: interfaces Keywords:
Cc: nthiery, embray Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by nthiery)

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")

Change History (14)

comment:1 Changed 19 months ago by nthiery

  • Description modified (diff)

comment:2 Changed 19 months ago by nthiery

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

Last edited 19 months ago by nthiery (previous) (diff)

comment:3 follow-up: Changed 19 months ago by 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

comment:4 Changed 19 months ago by fbissey

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

comment:5 in reply to: ↑ 3 ; follow-up: Changed 19 months ago by embray

  • Milestone changed from sage-8.7 to sage-duplicate/invalid/wontfix

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.

comment:6 Changed 19 months ago by embray

  • Status changed from new to needs_review

comment:7 follow-up: Changed 19 months ago by fbissey

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.

comment:8 in reply to: ↑ 7 Changed 19 months ago by embray

Replying to fbissey:

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 :/

comment:9 in reply to: ↑ 5 Changed 19 months ago by nthiery

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.

comment:10 Changed 19 months ago by arojas

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?

comment:11 Changed 19 months ago by arojas

Answering to myself: yes, this seems to be intentional

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

So xgap should definitely be blacklisted here.

comment:12 Changed 19 months ago by arojas

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.

comment:13 Changed 19 months ago by embray

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.

comment:14 Changed 19 months ago by embray

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 =_=

Note: See TracTickets for help on using tickets.