tests that libgap works correctly with kernel modules - draft

[dimpase]

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 #5232

When done, this PR will allow testing for the latter issue - which needs to be fixed elsewhere.

[dimpase]

this most probably will need a tweaking of Makefile.rules

[dimpase]

@fingolfin - how can we make sure in Makefile.rules (?) that io is installed for this test?

[fingolfin]

Thanks, it is a good idea to test that kernel extensions work with libgap.

Indeed, we already test that, as part of the testmakeinstall CI test, which runs make install, then builds mockpkg against that and tries loading it.

This PR however tests for something else: it builds a package against a non-installed gap (which is not using libgap) and then tries to load it in a separate binary which does use libgap. There is no promise whatsoever that this works, and so this is not supported, even though it currently may work in some setups (but this may change in the future).

[dimpase]

it builds a package against a non-installed gap (which is not using libgap) and then tries to load it in a separate binary which does use libgap.

Do you say that io.so is somehow made aware of libgap if it's built against gap linked to libgap ?

I don't understand why io.so is really different from a "usual" dylib that may be loaded by any
other dylib or executable that knows how to do it?
Both gap and libgap know how to load dynamic kernel modules, so it should not matter how exactly io.so is built, with gap linked to libgap, or with gap not linked to libgap.