Cannot load kernel extensions built against non-install GAP into an executable built against libgap
#5232
Comments
|
also, it can be triggered non-interactively. With the following change --- a/tst/testlibgap/basic.c
+++ b/tst/testlibgap/basic.c
@@ -6,6 +6,7 @@ int main(int argc, char ** argv)
{
printf("# Initializing GAP...\n");
GAP_Initialize(argc, argv, 0, 0, 1);
+ test_eval("LoadPackage(\"io\");");
test_eval("1+2+3;");
test_eval("g:=FreeGroup(2);");
test_eval("a:=g.1;");by running |
|
There is no issue with GAP 4.11.1. Unless someone can tell straight away where the regression was introduced, I'll do a |
|
I can't think of anything, and at first glance AssGVar doesn't look like a function we treat unusually. |
|
bisecting now, at most 10 runs to go :-) |
|
according to |
as a test, we load IO package - assuming it was built so that its kernel module is created. That was missing, and caused a regression reported in gap-system#5232
|
Fixed in #5235. |
fingolfin
changed the title
io is built (split out of #5230)libgap
|
probably not related, but testing without the bad commit produces two errors in |
|
After looking this in details, I disagree that there is a bug here: you built a kernel extension against a non-installed In the long run, I don't expect this to work at all. In the short run, I was able to find a workaround, which is in PR #5235. But the initial assessment, that "libgap is broken in the current master" is simply not accurate. It works fine, also with kernel extensions, as long as you built the kernel extension against libgap (i.e., If there is genuine need to load packages in |
|
once again, how does there is no libgap there to talk about. |
|
oh, wait, it does?! |
|
I have never seen a package where the linkage of an installed executable changes this way after installation... |
|
I still would like to see a test showing that libgap can load |
well, Are you saying this might break in the future because of... reasons? But that's precisely what |
|
and as far as |
Oops, I was on a wrong branch, on With this, it's really not clear how using installed |
|
I'd like to point out that it's normal for extensions to an interpreter to be interoperable with being used directly on the interpreter, as well as in a library that wraps it, to allow interpreter embedding. E.g. Python ( Are you sure you're not inventing a square wheel in #5193 ? |
I'd like to create a release GAP tarball from the master branch, to see that actually it does fix our Sagemath issue on macOS without #5235. How does one do it locally (I can only see instructions for releasing GAP using GH Actions, not what I want) ? |
Actually, on macOS, it is (well, against Python.framework, which is the macOS equivalent); note how macOS is the same platform on which you had a problem with gap vs. libgap... Makes you wonder, doesn't it? See, you make a claim about what is "normal" and then give one data point, which is then only half-accurate cough. But even if you gave ten examples: how is that a valid technical argument? Lots of bad things are done by "almost every project doing X" for any given X. Don't you think it would be better be to ask why we (and Python) do certain things in a certain way? Also notice how python has a few orders of magnitude more person power and resources. They also have generally different constraints and priorities. Things that work great for Python may simply be infeasible for us. So yeah, they do things differently from us, but in first approximation, that means nothing. So overall I find this point irrelevant and somewhat condescending ("sage devs telling stupid gap devs how the world works")
Yes, I am, thank you for asking. And I'd be surprised if there wasn't software on your compute using the same technique, because GNU libtool uses it extensively...
See |
I said that interoperability is normal. The last sentence of the quoted by you paragraph is also correct, contrary to what you wrote, because This |
|
It's, however, fair to say that |
libgapis broken in the current master and in 4.12.1 (but still OK on 4.11.1) on macOS 13.0.1 ifiois built, as can be seen by runningtst/testlibgap/basic: (which is built bymake testlibgap, for instance)On linux this works fine:
Originally posted by @dimpase in #5230 (comment)
The text was updated successfully, but these errors were encountered: