[BUG] IlmBase/OpenEXR linkage no longer respects LINKSTATIC build option

[nrusch]

trafficstars

Describe the bug

It looks like the changes in ab3f04204ba228ca778044c7a4e84d157695e4aa have broken static linkage of IlmBase/OpenEXR when LINKSTATIC is enabled.

To test, I've performed builds with identical arguments and dependencies using Release-2.2.8.0 and ab3f04204ba228ca778044c7a4e84d157695e4aa (building against IlmBase/OpenEXR 2.5.5), and compared the ldd output for libOpenImageIO.so. The Release-2.2.8.0 build has no dynamic links to IlmBase/OpenEXR, while the latter does. This issue persists through the latest 2.2 releases (2.2.13.0 as of today).

Build Configuration:

    cmake
    -G "Unix Makefiles"
    -D CMAKE_INSTALL_PREFIX=${REZ_INSTALL_PREFIX}
    -D CMAKE_BUILD_TYPE=${REZ_RELEASE_TYPE}
    -D CMAKE_EXE_LINKER_FLAGS=-Wl,--enable-new-dtags
    -D CMAKE_SHARED_LINKER_FLAGS=-Wl,--enable-new-dtags
    -D CMAKE_CXX_STANDARD=11
    -D BUILD_SHARED_LIBS=ON
    -D LINKSTATIC=ON
    -D EMBEDPLUGINS=ON
    -D GLIBCXX_USE_CXX11_ABI=0
    -D USE_SIMD=sse4.2
    -D TIFF_INCLUDE_DIR=${tiff_INCLUDE_DIRS}
    -D TIFF_LIBRARY=${tiff_libtiff_STATIC_LIBRARY}
    -D PNG_PNG_INCLUDE_DIR=${png_INCLUDE_DIRS}
    -D PNG_LIBRARY=${png_libpng15_STATIC_LIBRARY}
    -D JPEG_INCLUDE_DIR=${jpeg_INCLUDE_DIRS}
    -D JPEG_LIBRARY=${jpeg_libjpeg_STATIC_LIBRARY}
    -D CMAKE_LIBRARY_PATH=${lcms_LIBRARY_DIRS}
    -D BUILD_MISSING_FMT=OFF
    -D BUILD_MISSING_PYBIND11=OFF
    -D Pybind11_ROOT=${REZ_PYBIND11_ROOT}
    -D BUILD_MISSING_ROBINMAP=OFF
    -D Robinmap_ROOT=${REZ_ROBIN_MAP_ROOT}
    -D USE_LIBRAW=ON
    -D LibRaw_ROOT=${REZ_LIBRAW_ROOT}
    -D USE_PYTHON=ON
    -D Python_ADDITIONAL_VERSIONS=${PYTHON_MAJOR_VERSION}.${PYTHON_MINOR_VERSION}
    -D USE_OPENCOLORIO=OFF
    -D USE_DCMTK=OFF
    -D USE_FFMPEG=OFF
    -D USE_FIELD3D=OFF
    -D USE_GIF=OFF
    -D USE_HDF5=OFF
    -D USE_LIBHEIF=OFF
    -D USE_OPENCV=OFF
    -D USE_OPENJPEG=OFF
    -D USE_OPENVDB=OFF
    -D USE_PTEX=OFF
    -D USE_QT=OFF
    -D USE_WEBP=OFF
    -D STOP_ON_WARNING=OFF
    -D VERBOSE=ON

Release-2.2.8.0 ldd output:

        linux-vdso.so.1 =>  (0x00007ffd8af39000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe427299000)
        libz.so.1 => /lib64/libz.so.1 (0x00007fe427083000)
        libm.so.6 => /lib64/libm.so.6 (0x00007fe426d81000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fe426b71000)
        librt.so.1 => /lib64/librt.so.1 (0x00007fe426969000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007fe426765000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fe42645e000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe426248000)
        libc.so.6 => /lib64/libc.so.6 (0x00007fe425e7a000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fe42874d000)

ab3f04204ba228ca778044c7a4e84d157695e4aa ldd output:

        linux-vdso.so.1 =>  (0x00007ffd72dd4000)
        libIlmImf-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libIlmImf-2_5.so.25 (0x00007f3079dc9000)
        libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f3079bad000)
        libz.so.1 => /lib64/libz.so.1 (0x00007f3079997000)
        libm.so.6 => /lib64/libm.so.6 (0x00007f3079695000)
        libbz2.so.1 => /lib64/libbz2.so.1 (0x00007f3079485000)
        librt.so.1 => /lib64/librt.so.1 (0x00007f307927d000)
        libdl.so.2 => /lib64/libdl.so.2 (0x00007f3079079000)
        libImath-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libImath-2_5.so.25 (0x00007f3078e60000)
        libIexMath-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libIexMath-2_5.so.25 (0x00007f3078c5c000)
        libHalf-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libHalf-2_5.so.25 (0x00007f3078a19000)
        libIlmThread-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libIlmThread-2_5.so.25 (0x00007f3078810000)
        libIex-2_5.so.25 => /luma/dev/ruschn/rez-release/openexr/2.5.5/platform-linux/gcc-4.8.3/lib64/libIex-2_5.so.25 (0x00007f30785a3000)
        libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f307829c000)
        libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f3078086000)
        libc.so.6 => /lib64/libc.so.6 (0x00007f3077cb8000)
        /lib64/ld-linux-x86-64.so.2 (0x00007f307b2c6000)

Platform information:

• OS: CentOS 7.7/7.8
• C++ compiler: GCC 4.8.5

[nrusch]

Hey @lgritz , I just wanted to check in and see if you think this is something you might be able to take a look at sometime soon, or if I would be better off trying to chase it down on our end.

[lgritz]

@nrusch I haven't gotten a chance yet, just very busy. I don't tend to use static libs myself, so I'm just fumbling around with it. If you are able to take a stab at this, that would be much appreciated.

[nrusch]

OK, I started looking into this today, and I've been able to get the OIIO build pulling in the static libs at link time, but it's still linking to the dynamic libs as well. It's looking like the culprit may be IlmBase/OpenEXR installing CMake configurations that don't work right for their static builds (basically, the static targets end up pulling in the dynamic versions of their dependencies due to a bad configuration). Hoping to have a more conclusive answer soon.