ilmbase are deprecated or disabled.

[marsxxl]

Machine : M1 Mac mini
Version : 11.3.1 (20E241)
Terminal : iTerm2 3.4.6

Warning: Some installed formulae are deprecated or disabled.
You should find replacements for the following formulae:
ilmbase

[meshula]

IlmBase has been superceded by Imath for OpenEXR 3.0. Perhaps open an issue at the Neofetch repo, I don't see any related issues there yet. https://github.com/dylanaraps/neofetch/issues

[GeneralAccess]

I have a Flatpak with ilmbase as a dependency, it used to work (runtime: org.gnome.Platform runtime-version: "40"
sdk: org.gnome.Sdk), with some warnings:

/app/include/OpenEXR/ImathMatrix.h:2814:36: warning: dynamic exception specifications are deprecated in C++11 [-Wdeprecated]
 2814 | Matrix44<T>::invert (bool singExc) throw (IEX_NAMESPACE::MathExc)

Since the Flatpak platform has changed to 41 I get many of these errors and it fails:
_ImathMatrix.h:275:25: error: ISO C++17 does not allow dynamic exception specifications_

I don't normally use C++, but I am guessing that something that was deprecated in C++11 causes an error in C++ 17. The GitHub repository https://github.com/aforsythe/IlmBase hasn't changed for nine years, so I assume it is defunct.

I believe that although earlier versions of openexr depended on ilmbase, version 3.1.3 no longer does, however I get errors if I remove it:

========================================================================
Building module openexr in /home/chris/.flatpak-builder/build/openexr-3
========================================================================
Error: module openexr: Can't find autogen, autogen.sh or bootstrap

A previous post appears to suggest that I should include imath instead:
https://sourceforge.net/projects/ooo-imath/files/iMath-2.3.0/imath_2.3.0.tar.gz
So being no C expert I copied the Flatpak section for ilmbase and tried this:

  - name: imath
    config-opts:
      - --disable-static
    sources:
      - type: archive
        url: https://sourceforge.net/projects/ooo-imath/files/iMath-2.3.0/imath_2.3.0.tar.gz
        sha256: 4794c19bf6d613e23b77577b798d0b06bd9a4d57bf222885bba15cac7f0d5e72

However it fails with:

checking for GINAC... no
configure: error: Package requirements (ginac >= 1.7.1) were not met:
Package 'ginac', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables GINAC_CFLAGS
and GINAC_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Error: module imath: Child process exited with code 1

Maybe I need to include ginac as well, but knowing nothing about these packages or compiling C programs, I've decided that I should stop digging and ask for advice.

[meshula]

The aforsythe repo, and the ooo-imath repo, seem to be quite old copies of the real repo. I imagine someone made them in order to freeze our libraries in time a long time ago.

I poked around on FlatHub to see where OpenEXR is being used, and I noticed dependencies in things like vipsdisp. In that package, they apply local hacks and patches to the very old libraries.

I'm not sure if it is a reasonable amount of work to try to breathe life back into very old code like that, because as you noticed, the C++ language itself changed ten years ago.

The new versions of OpenEXR are easier to deal with than the old ones, and have been updated to compile successfully with new versions of C++.

Maybe the best way forward is to contact the maintainer of the package you are interested in with the very old dependency, and invite them to this thread. We could answer their questions on how to migrate their code to a maintained version of OpenEXR.

That would be ideal, because if packages were updated, then there would be no need for those very old unmaintained copies of OpenEXR and IlmBase all over the internet.

[GeneralAccess]

the best way forward is to contact the maintainer of the package

That's me :).

how to migrate their code to a maintained version of OpenEXR.

Isn't 3.1.3 the latest openexr then?

[meshula]

Haha great, welcome :)

It would be good to know what the dependency tree is for your project, and how it's built, in order to understand how to move forward.

Is your project here on github or another source repository that you can point us to?

[GeneralAccess]

Is your project here on github

My package is https://github.com/flathub/com.github.PopoutApps.popout3d https://github.com/PopoutApps/popout3d . It has a dependency on Hugin's align-image-stack which has several dependencies including openexr. The modules in the yml file are all for align-image-stack except Python-PIL and the app module itself.
Can be built on org.gnome.Platform runtime-version: "40" but not 41.

[meshula]

Here's one place to start:

ukoethe/vigra#496

Your project depends directly on vigra, and the Fedora maintainers have updated vigra for OpenEXR3. The vigra project has not yet adopted the change. I suggest adding a note on that issue that your project is moving to OpenEXR3, so incorporated the suggested patch would be of use.

Hugin is already compatible with OpenEXR 3, so that's good.

https://sourceforge.net/p/hugin/hugin/ci/default/tree/CMakeModules/FindOpenEXR.cmake

So at first glance, it seems like an update to vigra would be a first step.

[waebbl]

Hugin is already compatible with OpenEXR 3, so that's good.

https://sourceforge.net/p/hugin/hugin/ci/default/tree/CMakeModules/FindOpenEXR.cmake

@ChrisOfBristol Be sure to pull the latest 2021.0 beta release, not the 2020.0 you are currently using. The latter does not support OpenEXR 3.

[GeneralAccess]

pull the latest 2021.0 beta release

Will do, thanks.

[GeneralAccess]

update to vigra

I think you mean that this is needed for OpenEXR3 which can be used by Hugin. I will have to wait for the maintainer of vigra to do this update.
Does switching to OpenEXR3 mean that I will no longer need ilmbase and won't need to replace it with imath?

[meshula]

Looking at your code, I don't spot that you are importing imath directly, so that would make it just a dependency for the other packages you are using. So my impression is that you will not need to specify ilmbase or imath yourself.

[GeneralAccess]

you will not need to specify ilmbase or imath

So when vigra is updated, I can use OpenEXR3 which doesn't need ilmbase. I'll just have to stick with org.gnome.Platform runtime-version: "40" until that happens, as I'm not up to patching vigra.

[GeneralAccess]

I've been able to create a patched version of vigra, but openexr (which is before vigra in the Flatpak) fails with

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Building module openexr in /home/chris/.flatpak-builder/build/openexr-8
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Error: module openexr: Can't find autogen, autogen.sh or bootstrap

Because (as stated above) openexr 3 needs the update to vigra, I thought I might need to put vigra before openexr. That fails with

= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Building module vigra in /home/chris/.flatpak-builder/build/vigra-2
= = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = = =
Error: module: vigra: Can't find CMakeLists.txt

I don't know whether that is because something is missing from vigra and/or openexr, or because I'm trying to build vigra before openexr, or because I need to change the way they are compiled now. I write in Python, so as mentioned above, I'm guessing when trying to compile C++.

[meshula]

That's two problems. Maybe look at the first problem first?

It is saying that it can't find autogen or bootstrap. That means flatpak is trying to build OpenEXR using the old automake tools.

Support for autoconf and all of that was removed in OpenEXR3 because we decided to only support cmake builds.

So the necessary patch in the flatpak builder is that it needs to call CMake instead of autoconf.

If you build OpenEXR first, the flatpak builder doesn't have to build OpenEXR, so the problem with it calling the old build system doesn't trigger.

I think even if you build OpenEXR first by yourself, flatpak is going to be a little confused because it thinks that the build chain for vigra is described accurately in flatpak, but it isn't, because of that autoconf based OpenEXR 2 build.

[GeneralAccess]

That's two problems. Maybe look at the first problem first?

That was a mistake, I decided to leave the 2nd out but messed up the editing...

...the necessary patch in the flatpak builder is that it needs to call CMake...

  - name: openexr
    config-opts:
      - --disable-static
    sources:
      - type: archive
        #1.5.3 try 3.1.3 when vigra has been fixed. Should then be able to remove ilmbase and use version 41
        url: https://github.com/AcademySoftwareFoundation/openexr/archive/refs/tags/v3.1.3.tar.gz
        sha256: 6f70a624d1321319d8269a911c4032f24950cde52e76f46e9ecbebfcb762f28c
    cleanup:
      - /bin
      - /share/doc

It doesn't refer to autoconf, perhaps that is the default. Other modules have
buildsystem: cmake

vigra has
buildsystem: cmake-ninja

I tried both of those statements they didn't like
config-opts: - --disable-static
so I removed that. Both fail complaining of no Imath.

  By not providing "FindImath.cmake" in CMAKE_MODULE_PATH this project has
  asked CMake to find a package configuration file provided by "Imath", but
  CMake did not find one.
...
...

[meshula]

That last message, about FindImath.cmake means that ImathConfig.cmake was not installed, or that if it was installed, it's not in a place that cmake knows how to look. Unfortunately I don't know anything about flatpak, and can't do much beyond telling you what the error messages mean. I wonder if there are any flatpak gurus to invite to this thread?

[GeneralAccess]

That last message, about FindImath.cmake means that ImathConfig.cmake was not installed

meshula commented above:

_my impression is that you will not need to specify...imath yourself.

Since that is not the case, I tried:

  - name: imath
    config-opts:
      - --disable-static
    sources:
      - type: archive
        url: https://sourceforge.net/projects/ooo-imath/files/iMath-2.3.0/imath_2.3.0.tar.gz
        sha256: 4794c19bf6d613e23b77577b798d0b06bd9a4d57bf222885bba15cac7f0d5e72

However it fails with:

_checking for GINAC... no
configure: error: Package requirements (ginac >= 1.7.1) were not met:
Package 'ginac', required by 'virtual:world', not found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
Alternatively, you may set the environment variables GINAC_CFLAGS
and GINAC_LIBS to avoid the need to call pkg-config.
See the pkg-config man page for more details.
Error: module imath: Child process exited with code 1_

That appears to require installing yet another dependency or adjusting environment variables, which I know nothing about. That all seemed to be getting more complicated rather than less and was the reason for my first post.

[meshula]

I was mistaken when I said that sourceforget.net/projects/ooo-imath is an old fork of imath. It is a completely unrelated project with the same name, and coincidentally similar version numbers. The url for imath should refer to here, not that unrelated sourceforge project.

[GeneralAccess]

The url for imath should refer to here,

That works, thanks, I'm glad I didn't go down the rabbit-hole with the other reference :).
Imath compiles and so does OpenEXR, but the building process then fails on vigra. It's all related, but perhaps I need to pursue the vigra problem elsewhere.

[meshula]

Imath/OpenEXR compiles

That's awesome, congrats on the crossing the first hurdle.

Now that you have that working, perhaps it's time to try the vigra patch from the fedora website once more?

https://src.fedoraproject.org/rpms/vigra/blob/rawhide/f/vigra-openexr3.patch

[GeneralAccess]

perhaps it's time to try the vigra patch from the fedora website once more?

That's beyond me, but someone suggested this:

sudo dnf -y install fedpkg
fedpkg clone --anonymous vigra
cd vigra
fedpkg prep
This will create a vigra-1.11.1 sub-directory which will have all of the Fedora patches applied.

Which works, but the compilation by the Flatpak module:

  - name: vigra
    buildsystem: cmake-ninja
    config-opts:
       - -DWITH_OPENEXR=ON
    sources:
      - type: archive
        path: /home/vigra-1.11.1.tar.gz
    cleanup:
      - /bin
      - /doc
      - /lib/vigra/
      - /share

fails with both cmake and cmake-ninja with errors starting with:

CMake Warning (dev) in CMakeLists.txt:
  No project() command is present.  The top-level CMakeLists.txt file must
  contain a literal, direct call to the project() command.  Add a line of
  code such as
    project(ProjectName)
  near the top of the file, but after cmake_minimum_required().

and ending with:

-- Build files have been written to: /run/build/vigra
[1/22] Building CXX object impex/CMakeFiles/vigraimpex.dir/bmp.o
FAILED: impex/CMakeFiles/vigraimpex.dir/bmp.o 
/usr/bin/c++   -O2 -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -fexceptions -fstack-protector-strong -grecord-gcc-switches -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -MD -MT impex/CMakeFiles/vigraimpex.dir/bmp.o -MF impex/CMakeFiles/vigraimpex.dir/bmp.o.d -o impex/CMakeFiles/vigraimpex.dir/bmp.o -c /run/build/vigra/impex/bmp.cxx
/run/build/vigra/impex/bmp.cxx:38:10: fatal error: vigra/config.hxx: No such file or directory
   38 | #include "vigra/config.hxx"
      |          ^~~~~~~~~~~~~~~~~~
compilation terminated.
ninja: build stopped: subcommand failed.
Error: module vigra: Child process exited with code 1

[meshula]

The vigra CMakeLists.txt file DOES have a top level project() command, and the minimum required line, as do Imath, and OpenEXR. I wonder why it's emitting that message. Maybe the flatpak project is finding some other cmakelists.txt that is not the top level one.

[meshula]

A good idea would probably be to build vigra directly first as an experiment in the way the vigra project is built natively without flatpak. If you can build it in the normal way, then at least you know it can be built. The next step would then be applying that knowledge to troubleshooting the flatpak build.

by normal, I mean clone vigra into ${VDIR} then

mkdir vigra-build; cd vigra-build
cmake ${VDIR} -DCMAKE_INSTALL_PREFIX=${OPENEXR_IMATH_INSTALLATION_DIR}
make install

where ${VDIR} is the location you chose to put the source code, and ${OPENEXR_IMATH_INSTALLATION_DIR} is the directory that has the installed/compiled components, such as /usr/local, or wherever you chose.

[GeneralAccess]

build vigra directly first

Good idea, I installed cmake and tried
cmake /home/chris/vigra-build -DCMAKE_INSTALL_PREFIX=${OPENEXR_IMATH_INSTALLATION_DIR}
which ran with errors, presumably caused by not specifying the second directory. I don't think this will work as the other dependencies like imath or openexr aren't installed. They are only installed within the environment the Flatpak is being built in. I assume it would work if I attempted to compile and install all the dependencies first.

[meshula]

yes, that makes sense.