-
Notifications
You must be signed in to change notification settings - Fork 617
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
"IlmImf-2_3.dll" shared library is not built anymore in 2.3.0. #572
Comments
Could you update to the newer 2.4.0 release? It’s feature compatible and
comes with a much improved cmake build system. At this point, our answer to
pretty much any build-related problem with 2.3 is to try 2.4 if at all
possible.
On Wed, Sep 25, 2019 at 9:04 PM Thomas Mansencal ***@***.***> wrote:
Hi,
We are on Windows and I built OpenEXR 2.3.0 a few weeks ago to update from
our 2.2.0 version, so far so good until today when I tried to launch
oiiotool in our subsequently updated lOpenImageIO 1.8.17 version. It
complained about missing *IlmImf-2_3.dll* which surprised me:
[image: image]
<https://user-images.githubusercontent.com/99779/65657134-48950800-e076-11e9-8274-7e3aafdca740.png>
However, when looking at our build, there is indeed no shared library, a
static *IlmImf-2_3.lib* was built instead.
At first glance, there is nothing really specific in our build script that
could have caused that:
local('call vcbuildtools.bat amd64 && '
'cd /d {0} && '
'cmake '
'-DCMAKE_INSTALL_PREFIX={1} '
'-DOPENEXR_BUILD_PYTHON_LIBS=0 '
'-DZLIB_ROOT={2} '
'-DBOOST_ROOT={3} '
'-G "Visual Studio 14 2015 Win64" '
'-T v140,host=x64'.format(
build_directory,
RELEASE_DIRECTORY,
os.path.join(os.environ['REZ_ZLIB_ROOT'], 'zlib'),
os.path.join(os.environ['REZ_BOOST_ROOT'], 'boost'),
))
Any help would be appreciated!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#572>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFC3DGIJG42TMPRRIDUFVVDQLQYGLANCNFSM4I2UXJSA>
.
--
Cary Phillips | R&D Supervisor | ILM | San Francisco
|
Hi Cary, I think it is because of this CMake option: https://github.com/openexr/openexr/blob/0ac2ea34c8f3134148a5df4052e40f155b76f6fb/CMakeLists.txt#L55 Regarding 2.4.0, I can surely try but we would be keen on trying to stay aligned with the VFX Reference Platform and 2.3.x is the recommended version for 2019 and 2020. Cheers, Thomas |
Hi Thomas, |
Hi Peter, Yes, I was indeed compiling from the v2.3.0 tag. I think that I'm unfortunately entering the CMake conditional that forces the static ILM Base lib: Cheers, Thomas |
I recently ran into this too, a couple weeks ago when setting up OIIO's experimental GitHub Actions CI for Windows -- building the OpenEXR dependency I found myself missing this one dll. I'm afraid I didn't dig into it nearly as far as you did. My solution was just to build 2.4 instead and hope that it worked, and it did, and I did not go back to diagnose the original problem (which, as somebody who hasn't used a windows machine since the early 90's, I don't fee qualified to do). |
Unfortunately the update to v2.4.0 brought some other problems, seems like the linker cannot find boost_python-vc140-mt-x64-1_66.lib, it was probably already an issue for v2.3.0 and I probably was able to avoid the problem with
I will open a new issue for that. @lgritz : I just realised that my entire latest build of OIIO is borked because of that missing DLL :) |
sounds like you don't need or care about the python bindings, in which case
just specify
…-DPYILMBASE_ENABLE=OFF
when you run cmake (don't forget to delete the cache file / folder prior to
re-running cmake)
Kimball
On Fri, Sep 27, 2019 at 9:22 AM Thomas Mansencal ***@***.***> wrote:
Unfortunately the update to v2.4.0 brought some other problems, seems like
the linker cannot find *boost_python-vc140-mt-x64-1_66.lib*, it was
probably already an issue for v2.3.0 and I probably was able to avoid the
problem with -DOPENEXR_BUILD_PYTHON_LIBS=0 but this does not work anymore:
***\openexr\build\platform-windows\arch-AMD64\openexr\PyIlmBase\PyImath\PyImathBasicTypes.cpp(86): note: see reference to function template instantiation 'void PyImath::add_arithmetic_math_functions<unsigned i
nt>(boost::python::class_<PyImath::UnsignedIntArray,boost::python::detail::not_specified,boost::python::detail::not_specified,boost::python::detail::not_specified> &)' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(54): note: see reference to class template instantiation 'boost::arg<9>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(53): note: see reference to class template instantiation 'boost::arg<8>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(52): note: see reference to class template instantiation 'boost::arg<7>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(51): note: see reference to class template instantiation 'boost::arg<6>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(50): note: see reference to class template instantiation 'boost::arg<5>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(49): note: see reference to class template instantiation 'boost::arg<4>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(48): note: see reference to class template instantiation 'boost::arg<3>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(47): note: see reference to class template instantiation 'boost::arg<2>' being compiled
***\boost\1.66.0.rf1\platform-windows\arch-AMD64\python-2.7.14\boost\boost/bind/placeholders.hpp(46): note: see reference to class template instantiation 'boost::arg<1>' being compiled
Generating Code...
LINK : fatal error LNK1104: cannot open file 'boost_python-vc140-mt-x64-1_66.lib' [***\openexr\build\platform-windows\arch-AMD64\openexr\PyIlmBase\PyImath\imath_python2.vcxproj]
I will open a new issue for that.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#572>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAHM3IEJKIR5CBG6OLIORVTQLURX5ANCNFSM4I2UXJSA>
.
|
I actually do care, the only reason I disabled the binding was because I wanted to get going with our USD build, ultimately I will need them. |
The reason BUILD_STATIC is forced on in the 2.3 release build is that the half tables, and b44 lookup tables can't be automatically built in a dynamic build. (In other words, changing that conditional logic will resurrect the previous bug that Half can't be built because toFloat.h and eLut.h are missing.) So, the system builds ilm base static, AND dynamic, the two aren't mutually exclusive. So the bug in the 2.3 build system lies elsewhere. Would it be sane/possible to backpatch the 2.4 build system into 2.3, and point release it as 2.3.1? Also we should ping the vfxplatform to specify 2.4.x for 2020 :\ |
Hi @meshula / Nick, That is what I gathered from the comment in the CMakeLists.txt file, I haven't had time to look unfortunately but it made me wonder if it is possible to entirely disable support for DWA and B44 and compression schemes. If they are imposing such limitations, they should be optional. We are actually NEVER using them anyway, so we would not miss them. I'm summoning @nickcannon here for the VFX Reference Platform related discussion :) |
Another option is to check in to half, dwa, and b44 tables, rather than generating them on the fly. That would also bypass this issue, save build time, and might be a simpler back-patch into 2.3. |
Hi, I recently noticed the IlmImf dll is incorrectly installed (on my Windows machine) to a root 'bin' folder: for instance if I build from somewhere in my I fixed this by applying the following patch (applied on the v2.3.0 tag):
I also noticed that the CMake scripts completely changed in 2.4.0, so maybe the problem is already fixed in that version. Anyway @KelSolaar if you didn't fix your problem, you might want to try my patch, my guess is you have the exact same problem :) And for trying v2.4.0, I'd love, but unfortunately I'm also kinda trying to follow the vfxplatforms.com references ... |
OpenEXR 2.4.0 is specified in the 2020 vfxplatform :) |
Ok, that was just edited between my comment and now, but that good to know ! Updating my repositories and testing ! |
Hi, Only got time to go back to that today! Damien (@ix-dcourtois), thanks for your patch, it worked here. Closing this thread for now. |
Hi,
We are on Windows and I built OpenEXR 2.3.0 a few weeks ago to update from our 2.2.0 version, so far so good until today when I tried to launch
oiiotool
in our subsequently updated OpenImageIO 1.8.17 version. It complained about missing IlmImf-2_3.dll which surprised me:However, when looking at our build, there is indeed no shared library, a static IlmImf-2_3.lib was built instead.
At first glance, there is nothing really specific in our build script that could have caused that:
Any help would be appreciated!
The text was updated successfully, but these errors were encountered: