[Cin] ilmbase/openexr crashes recovery
sge at nmr.nioch.nsc.ru
Wed Nov 17 07:33:13 CET 2021
On Wed, 17 Nov 2021, Andrew Randrianasulu via Cin wrote:
> >> yeah, sounds like forcing ilmbase/openexr to be built in statically is
> >> way to go...
> > Bullseye (a real system) where the IlmImf so file still cause an immediate
> > crash. The only way I can get rid of it in the build is to manually edit
> > configure.ac and comment it out. On the configure line, I have tried
> try to delete -dev version of openexr/ilmbase packages from system you
I am almost sure the source of the openexr problem in cin must be an
incompatibility between the openexr versions from thirdparty and that
installed in the system: these two may be different, and while compiling
cinelerra takes headers from /usr/include/OpenEXR, but then links with the
library from thirdparty.
Here I have found my personal memo of how to compile cinelerra-4.5 (HV
inspect FLAGS in *_config, *akefile on -I/usr/include/OpenEXR
change -I/usr/include/OpenEXR to -I$(includedir)/OpenEXR
make |& tee log
This means, after configure but before make I had to manually grep the whole
Cinelerra tree like this
fgrep -l I/usr/include/OpenEXR `find . -name '*akefile' -print`
Then edit in all that autogenerated makefiles all the references to
/usr/include/OpenEXR to point to the thirdparty's location, everything
manually, and only then execute make.
In my opinion, even the recent Cinelerra-HV still requires such manual
editing. But how in looks in Cin-GG, I did never inspect.
Of course, compilation of Cinelerra with openexr will succeed if by chance
the version of openexr in the system is accidentally the same as that in
I am sorry, I have no time just now. Could somebody try to grep Cin-GG tree
after configure, are there some refs to headers from /usr/include which
could be conflicting with thirdparty or not?
Novosibirsk Institute of Organic Chemistry
Lavrentjeva, 9, 630090 Novosibirsk, Russia
Email sge at nmr.nioch.nsc.ru
More information about the Cin