Skip to content
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

Closed
KelSolaar opened this issue Sep 26, 2019 · 15 comments
Closed

"IlmImf-2_3.dll" shared library is not built anymore in 2.3.0. #572

KelSolaar opened this issue Sep 26, 2019 · 15 comments
Milestone

Comments

@KelSolaar
Copy link

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:

image

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!

@cary-ilm
Copy link
Member

cary-ilm commented Sep 26, 2019 via email

@KelSolaar
Copy link
Author

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

@peterhillman
Copy link
Contributor

Hi Thomas,
Did you do this before doing the cmake/build process?
git checkout v2.3.0
That should maintain strict compatibility with the VFX Platform version.
If you built from the master branch a few weeks ago, you would have basically been building a pre-release version of 2.4.0.
Peter

@KelSolaar
Copy link
Author

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:
https://github.com/openexr/openexr/blob/0ac2ea34c8f3134148a5df4052e40f155b76f6fb/CMakeLists.txt#L53

Cheers,

Thomas

@lgritz
Copy link
Contributor

lgritz commented Sep 26, 2019

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).

@KelSolaar
Copy link
Author

KelSolaar commented Sep 26, 2019

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.

@lgritz : I just realised that my entire latest build of OIIO is borked because of that missing DLL :)

@kdt3rd
Copy link
Contributor

kdt3rd commented Sep 26, 2019 via email

@KelSolaar
Copy link
Author

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.

@meshula
Copy link
Contributor

meshula commented Sep 30, 2019

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 :\

@KelSolaar
Copy link
Author

KelSolaar commented Oct 1, 2019

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 :)

@meshula
Copy link
Contributor

meshula commented Oct 1, 2019

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.

@ix-dcourtois
Copy link

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 C: drive, IlmImf-2_3.dll is installed to C:/bin/IlmImf-2_3.dll (for me it wasn't that it's not built, it was just incorrectly installed)

I fixed this by applying the following patch (applied on the v2.3.0 tag):

diff --git a/OpenEXR/IlmImf/CMakeLists.txt b/OpenEXR/IlmImf/CMakeLists.txt
index e1a8740..d31cf68 100644
--- a/OpenEXR/IlmImf/CMakeLists.txt
+++ b/OpenEXR/IlmImf/CMakeLists.txt
@@ -2,14 +2,6 @@
 
 SET(CMAKE_INCLUDE_CURRENT_DIR 1)
 
-IF (WIN32)
-  SET(RUNTIME_DIR ${OPENEXR_PACKAGE_PREFIX}/bin)
-  SET(WORKING_DIR ${RUNTIME_DIR})
-ELSE ()
-  SET(RUNTIME_DIR ${OPENEXR_PACKAGE_PREFIX}/lib)
-  SET(WORKING_DIR .)
-ENDIF ()
-
 SET(BUILD_B44EXPLOGTABLE OFF)
 IF (NOT EXISTS "${CMAKE_CURRENT_BINARY_DIR}/b44ExpLogTable.h")
   SET(BUILD_B44EXPLOGTABLE ON)

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 ...

@meshula
Copy link
Contributor

meshula commented Nov 4, 2019

OpenEXR 2.4.0 is specified in the 2020 vfxplatform :)

@ix-dcourtois
Copy link

Ok, that was just edited between my comment and now, but that good to know ! Updating my repositories and testing !

@KelSolaar
Copy link
Author

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.

@cary-ilm cary-ilm added this to the v2.5.0 milestone Apr 27, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

7 participants