CMake builds produce invalid pkg-config files

[mbakke]

After updating IlmBase and OpenEXR to 2.4.0 and changing to CMake, IlmBase.pc and OpenEXR.pc contains bogus entries for libdir, etc.

Before:

$ cat IlmBase.pc
prefix=/gnu/store/p78hb0ifsam4d6l20sj69wzn262myx67-ilmbase-2.3.0
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
OpenEXR_includedir=${prefix}/include/OpenEXR

Name: IlmBase
Description: Base math and exception libraries
Version: 2.3.0
Libs: -L${libdir} -lImath -lHalf -lIex -lIexMath -lIlmThread -pthread
Cflags: -pthread -I${OpenEXR_includedir}

$ cat OpenEXR.pc
prefix=/gnu/store/i2gxm1zpz1yqcinycv85mjxiw99vqzy4-openexr-2.3.0
exec_prefix=${prefix}
libdir=${exec_prefix}/lib
includedir=${prefix}/include
OpenEXR_includedir=${prefix}/include/OpenEXR

Name: OpenEXR
Description: OpenEXR image library
Version: 2.3.0

Libs: -L${libdir} -lIlmImf
Cflags: -I${OpenEXR_includedir}
Requires: IlmBase
Libs.private: -lz

After:

$ cat IlmBase.pc
prefix=/gnu/store/zfqx6sd92bjxpfzq7wii7hn5f34s18qm-ilmbase-2.4.0
exec_prefix=bin
libdir=lib
includedir=include
libsuffix=-2_4
Name: IlmBase
Description: Base math and exception libraries
Version: 2.4.0
Requires:
Conflicts:
Libs: -L${libdir} -lImath${libsuffix} -lHalf${libsuffix} -lIex${libsuffix} -lIexMath${libsuffix} -lIlmThread${libsuffix} -pthread
Cflags: -pthread -I${includedir} -I${includedir}/OpenEXR

$ cat OpenEXR.pc
prefix=/gnu/store/qlijvn28x8h6fv85ph1p91c337hvf5dx-openexr-2.4.0
exec_prefix=bin
libdir=lib
includedir=include
OpenEXR_includedir=include/OpenEXR
libsuffix=-2_4

Name: OpenEXR
Description: OpenEXR image library
Version: 2.4.0

Libs: -L${libdir} -lIlmImf${libsuffix}
Cflags: -I${OpenEXR_includedir}
Requires: IlmBase
Libs.private: -lz

IlmBase and OpenEXR are built separately. It's not clear to me why $prefix is missing from the newer pkg-config files. Ideas?

[mbakke]

The autoconf based build system still produces working pkg-config files.

[kdt3rd]

This should be fixed by PR #608 on master, will be merged to 2.4 maintenance branch within 48 hours such that 2.4.1 will contain the fix. Thanks for reporting and suggesting a fix!

[antonio-rojas]

Looks like this never made it to 2.4

[richbobo]

Hi - I've been trying to get OpenEXR installed on macOS 10.14.6 without success. It looks like maybe this update would fix the problem? How can I get the fix?
Below are the errors I get:

/usr/local/include/OpenEXR/half.h:99:15: warning: defaulted function definitions are a C++11 extension [-Wc++11-extensions]
        half () = default;                  // no initialization
                  ^
    /usr/local/include/OpenEXR/half.h:102:16: warning: defaulted function definitions are a C++11 extension [-Wc++11-extensions]
        ~half () = default;
                   ^
    /usr/local/include/OpenEXR/half.h:103:27: warning: defaulted function definitions are a C++11 extension [-Wc++11-extensions]
        half (const half &) = default;
                              ^
    /usr/local/include/OpenEXR/half.h:104:16: warning: rvalue references are a C++11 extension [-Wc++11-extensions]
        half (half &&) noexcept = default;
                   ^
    /usr/local/include/OpenEXR/half.h:104:19: error: expected ';' at end of declaration list
        half (half &&) noexcept = default;
                      ^
                      ;
    /usr/local/include/OpenEXR/half.h:124:43: warning: defaulted function definitions are a C++11 extension [-Wc++11-extensions]
        half &              operator = (const half  &h) = default;
                                                          ^
    /usr/local/include/OpenEXR/half.h:125:31: warning: rvalue references are a C++11 extension [-Wc++11-extensions]
        half &              operator = (half  &&h) noexcept = default;
                                              ^
    /usr/local/include/OpenEXR/half.h:125:35: error: expected ';' at end of declaration list
        half &              operator = (half  &&h) noexcept = default;
                                                  ^
                                                  ;
    6 warnings and 2 errors generated.
    error: command 'clang' failed with exit status 1

[lgritz]

Is this an error you get building OpenEXR, or using OpenEXR?

It looks like you have forgotten the -std=c++11 compiler flag. OpenEXR 2.4 is C++11 minimum.

[richbobo]

It's a build error via python -m pip install openexr

[richbobo]

I'm fairly fluent in Python, but have little to no experience with compiled languages. The error message looks like something I might be able to fix if I knew how the edit the setup script, but unfortunately I don't know how. Any help would be greatly appreciated.

[richbobo]

I'm guessing that any edits would need to happen in OpenEXR.cpp...? Or, would it be an argument added to the setup.py script?

[richbobo]

OK, after actually reading the error output, it's obvious that the errors point to a section of /usr/local/include/OpenEXR/half.h - specifically, lines 99-125.
Here is that section:

    //-------------
    // Constructors
    //-------------

    half () = default;			// no initialization
    half (float f);
    // rule of 5
    ~half () = default;
    half (const half &) = default;
    half (half &&) noexcept = default;

    //--------------------
    // Conversion to float
    //--------------------

    operator		float () const;


    //------------
    // Unary minus
    //------------

    half		operator - () const;


    //-----------
    // Assignment
    //-----------

    half &		operator = (const half  &h) = default;
    half &		operator = (half  &&h) noexcept = default;

Do you have an idea what/where it needs to be changed...?

[lgritz]

As I said earlier, the problem is not a bug in this code, the problem is that when it's compiled, somebody forgot the -std=c++11 argument to the C++ compiler. This is valid C++11 code that was being compiled by a C++03 compiler.

[peterhillman]

Presumably 'pip install openexr' installs this: https://pypi.org/project/OpenEXR
These python bindings are not part of the OpenEXR distribution and apparently have not been updated for some time.
It's possible that module can be fixed by adding -std=c++11 to the extra_compile_flags in the setup.py in that project. It might be better to report the issue to the author of that python module directly.

Alternatively, you can also read and write OpenEXR images with the OpenImageIO python bindings

[richbobo]

I was able to get OpenEXR to install by adding -std=c++11 to the extra_compile_flags in setup.py, as Igritz and peterhillman suggested. Here's the file with it added:

from distutils.core import setup
from distutils.extension import Extension
from distutils.command.build_py import build_py as _build_py

from os import system

from distutils.core import setup, Extension

version = "1.3.2"
setup(name='OpenEXR',
  author = 'James Bowman',
  author_email = '[email protected]',
  url = 'http://www.excamera.com/sphinx/articles-openexr.html',
  description = "Python bindings for ILM's OpenEXR image file format",
  long_description = "Python bindings for ILM's OpenEXR image file format",
  version=version,
  ext_modules=[ 
    Extension('OpenEXR',
              ['OpenEXR.cpp'],
              include_dirs=['/usr/include/OpenEXR', '/usr/local/include/OpenEXR', '/opt/local/include/OpenEXR'],
              library_dirs=['/usr/local/lib', '/opt/local/lib'],
              libraries=['Iex', 'Half', 'Imath', 'IlmImf', 'z'],
              extra_compile_args=['-g', '-std=c++11', '-DVERSION="%s"' % version])
  ],
  py_modules=['Imath'],
)

Then, I did python setup.py install in the terminal.

[richbobo]

I was able to import OpenEXR and I ran OpenEXR.isOpenExrFile() on a .exr file and a .jpg file on my Desktop, which returned True and False, as expected.

Thanks for the help, and I'll see about reporting the issue to the author!

Now to dig in and work on some scripts... 8^)

[mtsokol]

Hi @richbobo!
I got stuck on this issue while installing tensorflow-graphics which require openexr via pip. Thank you for figuring it out, it helped a lot. (Other also still experience this: tensorflow/graphics#421)

Did you managed to contact the author of the package about releasing new version with fix for that?

[richbobo]

I regret to say that, no, I did not have the time to do that, sorry! Glad my post was a help to you, though.