libImath cannot open shared object [ linux ]

[CarloCattano]

running ProjectGenerator or attempting to run any compiled oF project, I get the same message:

projectGenerator: error while loading shared libraries: libImath-3_1.so.29: cannot open shared object file: No such file or directory

it kind of makes sense, since I only seem to have

❯ /usr/bin/ls libImath*
libImath-3_2.so  libImath-3_2.so.30  libImath-3_2.so.30.3.2.1  libImath.so

This is with latest git version

 pacman -Qs imath     
local/imath 3.2.1-1
    A C++ and python library of 2D and 3D vector, matrix, and math operations for computer graphics
                

any clues ?

[artificiel]

this is the classic dylib problem, where the system upgrades while the app refers to an older lib that's not there anymore. the proper binary distribution is to bundle everything into a flatpack/appImage, so the app carries it's libs.

as a hack you can try sudo ln -s /usr/lib/libImath-3_2.so.30 /usr/lib/libImath-3_1.so.29 and depending on the actual interaction with the lib, it may not segfault (the number coming after .so is related to the lib's ABI, different numbers indicates incompatibilities, but I doubt Project Generator makes any calls into that lib). you can also procure a copy of the older version of the lib (I'm attaching one, just in case it works). if you don't want to mess with /usr/lib you can use LD_LIBRARY_PATH to find libs elsewhere at runtime. I think putting the lib besides the compiled app or in it's data/ may also work.

contrarily to other distros that provide ways to install older versions of libs, Arch's rolling release approach is to clean slate everything, and there is no way to strictly tie a build to a "distribution version". the "Arch way" would be to recompile the packages that rely on outdated libs, but getting Project Generator to compile these days appears to be tricky...

libImath-3_1.so.29.zip

[CarloCattano]

Thanks , that was my first attempt to manually sym link it, but unfortunately it throws

./pong42: symbol lookup error: /usr/lib/libfreeimage.so.3: undefined symbol: _ZN7Imf_3_36HeaderC1ERKN9Imath_3_13BoxINS1_4Vec2IiEEEES7_fRKNS3_IfEEfNS_9LineOrderENS_11CompressionE
make: *** [../../libs/openFrameworksCompiled/project/makefileCommon/compile.project.mk:195: RunRelease] Error 127

at runtime after compilation

I did not try with your provided zip version, just within my system

❯ sudo ln -s /usr/lib/libImath-3_2.so.30 /usr/lib/libImath-3_1.so.29

I might have some misconfiguration going on, otherwise I would see more users experiencing this

[CarloCattano]

even compiling and installing the version of Imath there are other problems down the way

 projectGenerator .
projectGenerator: symbol lookup error: /usr/lib/libfreeimage.so.3: undefined symbol: _ZN7Imf_3_36HeaderC1ERKN9Imath_3_13BoxINS1_4Vec2IiEEEES7_fRKNS3_IfEEfNS_9LineOrderENS_11CompressionE

[artificiel]

ok well your OS is simply too recent to run the older software. how did you obtain the projectGenerator binary you're trying to run?

[CarloCattano]

I compiled it myself from source tar balls from gh

[artificiel]

was the tarball a nightly release or a specific numbered release? (which one)

and did you compile on a different machine or on this machine? and if this machine (assuming Arch Linux or a derivative), when was the compilation done?

trying to get a sense of the time span here — as a point of reference, I just tried some software compiled on Arch 2 years ago on an updated machine and have similar dylib trouble.

Arch Linux is not attempting to provide long-term stable ABIs (it's not like Ubuntu releases which are coherent) but instead presupposes software will be re-built as needed (for instance stuff coming from the AUR will require re-compilation as the library sonames change).

going back to OF, considering it's a developper environment with most project being used in-place by the developer, bundling libs in AppImages by default is overkill, but certainly makes sense if you are thinking of distributing the software. you can check this forum post https://forum.openframeworks.cc/t/dynamic-library-dependency-analysis/43406 for a visualization of the dylib dependencies (and sub-dependencies) comparing the app itself + interaction with the OS... it reveals the complexity of these dependencies.

there is an argument for compiling with static libs (.a) it may augment a bit the disk usage as libraries get copied within the app (they do get copied in AppImage also), but with "greedy" static libs it diminishes the number of dependencies. of course you still have to be compatible with the OS and in that regard Arch is the most aggressive in not maintaining compatibility... (and the most difficult to setup at a past point in time, whereas you can always install an old Ubuntu).

[danoli3]

I think we should just static all the libs for Linux as well

…

On Tue, 23 Sep 2025 at 9:53 am, alexandre burton ***@***.***> wrote: *artificiel* left a comment (openframeworks/openFrameworks#8472) <#8472 (comment)> was the tarball a nightly release or a specific numbered release? (which one) and did you compile on a different machine or on this machine? and if this machine (assuming Arch Linux or a derivative), when was the compilation done? trying to get a sense of the time span here — as a point of reference, I just tried some software compiled on Arch 2 years ago on an updated machine and have similar dylib trouble. Arch Linux is not attempting to provide long-term stable ABIs (it's not like Ubuntu releases which are coherent) but instead presupposes software will be re-built as needed (for instance stuff coming from the AUR will require re-compilation as the library sonames change). going back to OF, considering it's a developper environment with most project being used in-place by the developer, bundling libs in AppImages by default is overkill, but certainly makes sense if you are thinking of distributing the software. you can check this forum post https://forum.openframeworks.cc/t/dynamic-library-dependency-analysis/43406 for a visualization of the dylib dependencies (and sub-dependencies) comparing the app itself + interaction with the OS... it reveals the complexity of these dependencies. there is an argument for compiling with static libs (.a) it may augment a bit the disk usage as libraries get copied within the app (they do get copied in AppImage also), but with "greedy" static libs it diminishes the number of dependencies. of course you still have to be compatible with the OS and in that regard Arch is the most aggressive in *not* maintaining compatibility... (and the most difficult to setup at a past point in time, whereas you can always install an old Ubuntu). — Reply to this email directly, view it on GitHub <#8472 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAGK2HAE4VLAO5UALVB7X6L3UCDZJAVCNFSM6AAAAACGNDHAYSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTGMRRHEZDIMZXGA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[kflak]

I'm also having similar issues. After symlinking libOpenEXR, libIex, and libImath and still getting errors, I decided to give up for the time being. This is one of those extremely frustrating things with arch linux and openframeworks that (almost) makes me want to go the nixos way instead. Come to think of it, I could probably use a nix-shell to set up oF and all its dependencies to maintain a coherent dependency graph. Did anybody try something like this?

[kflak]

I think we should just static all the libs for Linux as well

I would love to see that happen! I have zero problems with a bit bigger download from oF if it means I get something that doesn't break every time I do an upgrade of my system. Don't even get me started on gstreamer....