AcademySoftwareFoundation / openexr

The OpenEXR project provides the specification and reference implementation of the EXR file format, the professional-grade image storage format of the motion picture industry.
http://www.openexr.com/
BSD 3-Clause "New" or "Revised" License
1.6k stars 606 forks source link

OpenEXR static build not creating libIlmImf.a #1770

Open SteveWDI opened 2 weeks ago

SteveWDI commented 2 weeks ago

Setting BUILD_SHARED_LIBS to OFF seems to create a static library for ilmThread, but not for IlmImf.

Environment:
    Docker container based on Centos:7
    updated
    'devtoolset-11' installed
    'scl enable devtoolset-11 bash' executed
    OpenSSL 1.1.1l installed  built/installed
    CMake  3.29.5 built/installed
    Freetype 2.11.0 built/installed

Steps to reproduce:
    wget https://github.com/AcademySoftwareFoundation/openexr/releases/download/v3.2.4/openexr-v3.2.4.tar.gz
    mkdir openexr-v3.2.4
    tar zxvf openexr-v3.2.4.tar.gz -C /openexr-v3.2.4
    rm openexr-v3.2.4.tar.gz
    cd /openexr-v3.2.4
    cmake -DCMAKE_CXX_STANDARD=17 -DBUILD_SHARED_LIBS=0 .
    make -j$(nproc)
    make install
If you then execute:
    find / -name "libIlm*" 

Returns:
    /usr/lib64/libIlmImf.so
    /usr/lib64/libIlmThread.so.6
    /usr/lib64/libIlmThread.so.6.0.0
    /usr/lib64/libIlmImf.so.7
    /usr/lib64/libIlmImf.so.7.0.0
    /usr/local/lib64/libIlmThread-3_2.a
    /usr/local/lib64/libIlmThread-3_2.so.31.3.2.4
    /usr/local/lib64/libIlmThread-3_2.so.31
    /usr/local/lib64/libIlmThread-3_2.so
    /usr/local/lib64/libIlmThread.so
    /src/lib/IlmThread/libIlmThread-3_2.a

Expected behavior: A libIlmImf.a library should be created.

I.e., it creates libIlmThread-3_2.a, but not an ILMImf equivalent.

cary-ilm commented 2 weeks ago

The libraries in /usr/lib/* appear to be from an older installation. Those should not be generated by your cmake invocation of v3.2.4. Are you picking those up from a base image somewhere?

OpenEXR v3.2.4 does not build any libraries with Imf in the name, that term was retired in the v3.0 release.

SteveWDI commented 2 weeks ago

The desire to reference IlmImf comes from this error when building an app using OIIO:

/opt/rh/devtoolset-11/root/usr/libexec/gcc/x86_64-redhat-linux/11/ld: /OpenImageIO-2.5.12.0/dist/lib64/libOpenImageIO.a(imagebufalgo_draw.cpp.o): in function std::_Function_handler<void (OpenImageIO_v2_5::ROI), OpenImageIO_v2_5::noise_uniform_<Imath_3_1::half>(OpenImageIO_v2_5::ImageBuf&, float, float, bool, int, OpenImageIO_v2_5::ROI, int)::{lambda(OpenImageIO_v2_5::ROI)#1}>::_M_invoke(std::_Any_data const&, OpenImageIO_v2_5::ROI&&)': imagebufalgo_draw.cpp:(.text+0xeb4f): undefined reference toimath_half_to_float_table'

I'm very confused because I thought the table was included in Imath, but it looks like Imath is no longer a part of OpenEXR...? Nor does it seem to be included with OIIO.

lgritz commented 2 weeks ago

The project split Imath (now producing libImath) into a separate project repo at version 3.0, and at that time, also the main OpenEXR library changed to be called libOpenEXR, not libIlmImf.

On Unix-like systems, dynamic libraries understand how to link their own dependencies. Static libraries do not. If you're linking static libOpenImageIO.a, and not using cmake and consuming OIIO's exported cmake config files, you'll need to -lStuff yourself to include the dependency libraries you need. In this case, it's Imath.

SteveWDI commented 1 week ago

Understood. Thanks, @lgritz, for your helpful response. I was confused by this line from the OIIO dependency definition:

- OpenEXR/Imath >= 3.1 (tested through 3.2 and main)

I thought it meant that OpenEXR and Imath were both contained together when in fact they are not and it's now necessary to download and build them separately. Imho, there should be two separate lines in the dependency list for OIIO, not one.

lgritz commented 1 week ago

It's only very recently in master (not yet in any official supported release) that we were 3.1+ only. For a very long time, we accepted either 2.x or 3.x. They were the same package in 2.x. So "OpenEXR/Imath" was meant indicate "either both package, if new, or the combined thing, if old."

Sorry, I will clarify the docs. I'm sure there are a few places where the wording is muddied because it used to describe a different situation.