Do we drop 32bit i386 support?

A point raised during today's yade-dev meeting: Do we drop 32bit i386 support?

Because i386 build and tests fail almost always (both asan and not asan). Summary from build output:

This is make_asan_i386: https://gitlab.com/yade-dev/trunk/-/jobs/1542965754 (quite frequent error):

testWrongFunctorType (yade.TestObjectInstantiation)
Core: dispatcher and functor type mismatch is detected ... ok
testErase (yade.TestBodies)
Bodies: erased bodies are None in python ... ok
testErasedAndNewlyCreatedSphere (yade.TestBodies)
Bodies: The bug is described in LP:1001194. If the new body was created after deletion of previous, it has no bounding box ... 
libgomp: Thread creation failed: Resource temporarily unavailable

And this is tst_bll_i386: https://gitlab.com/yade-dev/trunk/-/jobs/1542965778 (quite frequent error)

testWrongInput (yade.tests.testMath.SimpleTests) ... ok
testAssignment (yade.tests.enumTest.TestEnum) ... ok
testException (yade.tests.enumTest.TestEnum) ... 
  Here it must throw two exceptions:
<ERROR> ArbitraryEnum_from_python<yade::OpenGLRenderer::BlinkHighlight>:57 static bool yade::ArbitraryEnum_from_python<ArbitraryEnum>::setArbitraryEnum(const boost::python::api::object&, ArbitraryEnum&) [with ArbitraryEnum = yade::OpenGLRenderer::BlinkHighlight]: enum class yade::OpenGLRenderer::BlinkHighlight does not have key number: -100
/bin/bash: line 140:    12 Segmentation fault      install/bin/yade-ci --test

Both use the same image: image: registry.gitlab.com/yade-dev/docker-yade:debian-bullseye-i386.

I honestly don't know if we can fix these errors. I have no idea. They both may be the same thing which manifests differently because it is debug / non-debug build. I could not reproduce locally neither of these errors inside an i386 chroot. But sometimes I get locally a linker error when not using gold linker.

The only meaningful message I see is: "libgomp: Thread creation failed: Resource temporarily unavailable", which I have no idea what to do with.

@gladk let us discuss what we can do here. If we decide to remove it from pipeline, then are we officially dropping support for i386 platform? No debian packages for i386?

Do we revert the recent "split" changes, which I did, for example in VTKRecorder? (a side note: after "split" it is compiling faster). I did that "split" stuff hoping to fix the i386 crash in CI (#169 (closed), #223 (closed)). This motivation becomes void if we drop i386.

Perhaps now it is time to give up...?

@jduriez, @klausthoeni, @robcaulk, @bchareyre : I am open to all suggestions, let us try to find a reasonable solution.

Assignee Loading
Time tracking Loading