<div dir="ltr"><div class="gmail_default" style="font-size:small">Georgy,</div><div class="gmail_default" style="font-size:small">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.</div><div class="gmail_default" style="font-size:small">...Phyllis<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Nov 16, 2021 at 11:33 PM Georgy Salnikov via Cin <<a href="mailto:cin@lists.cinelerra-gg.org">cin@lists.cinelerra-gg.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Andrew, Phyllis,<br>
<br>
On Wed, 17 Nov 2021, Andrew Randrianasulu via Cin wrote:<br>
<br>
> >> yeah, sounds like forcing ilmbase/openexr to be built in statically is<br>
> >> way to go...<br>
> >><br>
> > Bullseye (a real system) where the IlmImf so file still cause an immediate<br>
> > crash.  The only way I can get rid of it in the build is to manually edit<br>
> > <a href="http://configure.ac" rel="noreferrer" target="_blank">configure.ac</a> and comment it out.  On the configure line, I have tried<br>
><br>
> try to delete -dev version of openexr/ilmbase packages from system you<br>
<br>
I am almost sure the source of the openexr problem in cin must be an<br>
incompatibility between the openexr versions from thirdparty and that<br>
installed in the system: these two may be different, and while compiling<br>
cinelerra takes headers from /usr/include/OpenEXR, but then links with the<br>
library from thirdparty.<br>
<br>
Here I have found my personal memo of how to compile cinelerra-4.5 (HV<br>
version):<br>
<br>
./configure<br>
<br>
inspect FLAGS in *_config, *akefile on -I/usr/include/OpenEXR<br>
change -I/usr/include/OpenEXR to -I$(includedir)/OpenEXR<br>
<br>
make |& tee log<br>
<br>
This means, after configure but before make I had to manually grep the whole<br>
Cinelerra tree like this<br>
<br>
fgrep -l I/usr/include/OpenEXR `find . -name '*akefile' -print`<br>
<br>
Then edit in all that autogenerated makefiles all the references to<br>
/usr/include/OpenEXR to point to the thirdparty's location, everything<br>
manually, and only then execute make.<br>
<br>
In my opinion, even the recent Cinelerra-HV still requires such manual<br>
editing. But how in looks in Cin-GG, I did never inspect.<br>
<br>
Of course, compilation of Cinelerra with openexr will succeed if by chance<br>
the version of openexr in the system is accidentally the same as that in<br>
thirdparty.<br>
<br>
I am sorry, I have no time just now. Could somebody try to grep Cin-GG tree<br>
after configure, are there some refs to headers from /usr/include which<br>
could be conflicting with thirdparty or not?<br>
<br>
Georgy<br>
_______________________________________________________________________________<br>
<br>
Georgy Salnikov<br>
NMR Group<br>
Novosibirsk Institute of Organic Chemistry<br>
Lavrentjeva, 9, 630090 Novosibirsk, Russia<br>
Phone   +7-383-3307864<br>
Email   <a href="mailto:sge@nmr.nioch.nsc.ru" target="_blank">sge@nmr.nioch.nsc.ru</a><br>
_______________________________________________________________________________<br>
<br>
-- <br>
Cin mailing list<br>
<a href="mailto:Cin@lists.cinelerra-gg.org" target="_blank">Cin@lists.cinelerra-gg.org</a><br>
<a href="https://lists.cinelerra-gg.org/mailman/listinfo/cin" rel="noreferrer" target="_blank">https://lists.cinelerra-gg.org/mailman/listinfo/cin</a><br>
</blockquote></div>