[Cin] ilmbase/openexr crashes recovery

Phyllis Smith phylsmith2017 at gmail.com
Wed Nov 17 20:16:26 CET 2021


Georgy,
Thanks so much for the analysis and advice! it gives us a direction to go.
I will do some checking based on my limited ability.
...Phyllis

On Tue, Nov 16, 2021 at 11:33 PM Georgy Salnikov via Cin <
cin at lists.cinelerra-gg.org> wrote:

> Andrew, Phyllis,
>
> 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
> version):
>
> ./configure
>
> 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
> thirdparty.
>
> 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?
>
> Georgy
>
> _______________________________________________________________________________
>
> Georgy Salnikov
> NMR Group
> Novosibirsk Institute of Organic Chemistry
> Lavrentjeva, 9, 630090 Novosibirsk, Russia
> Phone   +7-383-3307864
> Email   sge at nmr.nioch.nsc.ru
>
> _______________________________________________________________________________
>
> --
> Cin mailing list
> Cin at lists.cinelerra-gg.org
> https://lists.cinelerra-gg.org/mailman/listinfo/cin
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.cinelerra-gg.org/pipermail/cin/attachments/20211117/4654f5d9/attachment.htm>


More information about the Cin mailing list