ImageIO framework unusable

I’m getting the following error when running unit tests:

dyld: Library not loaded: /System/Library/Frameworks/ImageIO.framework/Versions/A/Resources/libGIF.dylib

Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

Reason: Incompatible library version: ImageIO requires version 1.0.0 or later, but libGIF.dylib provides version 0.0.0


Do you get this error locally?

I don’t know much about this library, but a newer macOS image may satisfy your requirements. See for the current choices.

I don’t have macOS so no idea. As the error shows a faulty system framework I believe the error is on travis due to some unsuitable components installed or some broken install.

I can try to change the osx image but that won’t solve the issue that the default image is broken.

xcode10 doesn’t work either:

dyld: Symbol not found: __cg_jpeg_resync_to_restart

Referenced from: /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

Expected in: /usr/local/lib/libJPEG.dylib

in /System/Library/Frameworks/ImageIO.framework/Versions/A/ImageIO

How about xcode11.3?

Same issue as with 10.0:

We can turn on the debug feature on this repository if you’d like, so that you can troubleshoot it more interactively. I don’t know enough about your code base to advise any further.

I think I’ll create a test repo just for that. To me it looks like a broken installation of the ImageIO Framework on the CI image and I guess I can reproduce it with a test using SDL or SDL2.

This is a very curious possibility. ImageIO is an Apple-provided framework, and if it’s installed incorrectly, I would think that only Apple can fix it.

On a few images I’ve checked, libGIF version is 1.0.0.

Examples: How DYLD_* Environmental Variables Break Mach-O Library Resolution suggests that using DYLD_LIBRARY_PATH can break dynamic linking in MacOS. Your build does seem to be using it.

Generally, to diagnose Cmake builds, you need to run cmake with --trace-expand to understand what exactly fails and what exact steps lead to it.

Not if you (or the code you call) mess with the system’s workings. So until you diagnose the issue, you can’t really be sure who is at fault.

Seems you are right with the paths. I was able to reproduce this:

1 Like

Ok the problem is fixed by not adding a /usr path to (DY)LD_LIBRARY_PATH. The issue just occurred recently because (I assume) Boost 1.71 was “recently” installed which made it pick up the newer boost instead of the expected one