-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use the C++ compiler to link semigroups.so #942
Conversation
Trying to work around #943 to test this atm. |
OK, I'm finally down to testing on OpenBSD. I use an external Eigen library (it's an OpenBSD package), and build/install
(these For For running GAP (and even for running So far I tested the rebased branch on #937, it works (package loads in GAP, Testing this branch now. The semigroups GAP package is configured with
|
This branch does not play as nice with tests.
|
Ah sorry, I now see you wrote in a previous comment that you first tested with PR #937 and it all passed and then did the same test with this PR here and it gave that crash, is that right? Is the |
some tests with #937 fail, with a bad alloc error, too, but GAP stays up. So it looks like it's a slightly different error handling, more robust. will post the logs |
OK, ran tests number of times, with both this and the old branch. The new branch doesn't really display a different behaviour (crashes don't happen during every run, and anyway it's a memory corruption/leak that finally brings GAP down sometimes). Leaking/broken test is apparently So here what all the logs I made have in common:
Also,when it comes to running these tests, memory used by GAP shots up by about 1GB - another indication of a leak to me. |
@fingolfin - a typo to be fixed on fingolfin#1 |
@dimpase the typo is not in this PR, though, wouldn't it make more sense to directly submit it to this repository? |
It's a typo made by you in an earlier iteration. Let's not be overtly bureacratic here. Doing it the other way would likely create a merge conflict to resolve. |
@dimpase can I have access to a machine where I can reproduce the bug? I agree with @fingolfin that this looks like an issue with the package or libsemigroups rather than the build system |
Absolutely, no problem. Email me the public part (.pub) of your ssh key. |
Hey @james-d-mitchell , you already have an account on this machine - you accessed in in June afaict. :-) |
??? This PR here may never be merged. Making a fix to something not touched by this PR only in here at best delays the fix from becoming generally available and at worst means the fix is never applied.
How? My PR does not even touch |
oh, OK, I confused it with Makefile.in |
Thanks @dimpase i will try to look asap, but probably not until Monday |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Tests fail, would be better if they passed |
Did they work before? They all (with exception of cygwin, which I can't say much about now) seem to fail due to inability to find libsemigroups at runtime, i.e. either LD_LIBRARY_PATH must be set, or better #938 resolved) |
Yes they passed before for example in your most recent pr. |
are they all running in miniconda environment with libsemigroups coming from conda? |
By the way, I ran
|
Seems to fail with the external libsemigroups. Are you sure that the failing tests aren't just because the test machine has limited memory, and the tests are legitimately using large amounts of memory? |
the machine has 2GB of physical RAM and 4GB of swap; and the default user is limited to processes using 4GB of memory. Do you really run tests which need gigabytes of RAM? |
Probably not, just checking! |
@fingolfin - I reproduced these CI errors locally on Debian oldstable linux. The problem is that these incantations on Linux don't lead to
|
Here is what the current main branch is doing instead
and this works correctly:
|
here is how to fix it - just to shuffle the arguments of the linking call around. Only checked on Linux. --- a/Makefile.gappkg
+++ b/Makefile.gappkg
@@ -138,7 +138,7 @@ gen/%.$(GAP_OBJEXT): %.s Makefile
# build rule for linking all object files together into a kernel extension
$(KEXT_SO): $(KEXT_OBJS)
@mkdir -p $(@D)
- $(QUIET_GAC)$(GAP_CXX) $(KEXT_LDFLAGS) $(KEXT_OBJS) -o $@ $(GAP_LDFLAGS) $(GAC_LDFLAGS)
+ $(QUIET_GAC)$(GAP_CXX) -o $@ $(GAP_LDFLAGS) $(GAC_LDFLAGS) $(KEXT_OBJS) $(KEXT_LDFLAGS)
# hook into `make clean`
clean: clean-kext |
@fingolfin - please see fingolfin#2 on my fork this CI step passes. I'll check the rest now. |
ba439a2
to
5cb736b
Compare
Thanks @dimpase I've updated this PR to fix the link order |
Thanks very much @fingolfin and @dimpase |
Resolves #928
This is a simpler (?) alternative to PR #937 and thus closes #937 if it gets merged.
@dimpase could you verify if this also resolves the issue (modulo #938 of course) for you?