tlRender

tlRender copied to clipboard

The Mac build puts the dylibs in the install folder, and references them there. The Otio libs expect to be copied as siblings to the executable.

Most likely, all the install/lib/ dylibs including otio's should be referenced as @loader_path/.../lib/libfoo.dylib

This likely involves install_name_tool shenanigans at the end of the build. Currently, I'm working around it by manually copying the otio dylibs into the bin dir (the example then runs properly)

otool -L ./tlrplay-glfw | grep dylib
	/usr/lib/libexpat.1.dylib (compatibility version 7.0.0, current version 8.0.0)
	@loader_path/libopentimelineio.dylib (compatibility version 0.0.0, current version 0.0.0)
	@loader_path/libopentime.dylib (compatibility version 0.0.0, current version 0.0.0)
	/Users/nporcino/dev/tlRender/build/install/lib/libavdevice.58.dylib (compatibility version 58.0.0, current version 58.13.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libavfilter.7.dylib (compatibility version 7.0.0, current version 7.110.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libavformat.58.dylib (compatibility version 58.0.0, current version 58.76.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libavcodec.58.dylib (compatibility version 58.0.0, current version 58.134.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libswresample.3.dylib (compatibility version 3.0.0, current version 3.9.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libswscale.5.dylib (compatibility version 5.0.0, current version 5.9.100)
	/Users/nporcino/dev/tlRender/build/install/lib/libavutil.56.dylib (compatibility version 56.0.0, current version 56.70.100)

I was just taking a look at this and it appears that OTIO is setting the "@loader_path"? https://github.com/PixarAnimationStudios/OpenTimelineIO/blob/068225674752a226381ea43fddaef22159e410fb/src/opentimelineio/CMakeLists.txt#L94

If I remove that from the OTIO CMake files then I get:

otool -L bin/tlrplay-glfw/tlrplay-glfw | grep opentime
	@rpath/libopentimelineio.dylib (compatibility version 0.0.0, current version 0.0.0)
	@rpath/libopentime.dylib (compatibility version 0.0.0, current version 0.0.0)

And if I run the executable it works, without manually copying the libraries or setting DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH:

otool -l bin/tlrplay-glfw/tlrplay-glfw | grep path
         name @rpath/libopentimelineio.dylib (offset 24)
         name @rpath/libopentime.dylib (offset 24)
         path /Users/darby/dev/otio/tlRender/build/install/lib (offset 12)

Oh geez, you know why we're doing that? It's because rpath's on python on the mac are set up to run relative to the python executable, not the consuming python module. frickin' frackin' mess :( I wonder if we need to add another option or internal variable, in otio's cmake scripts, to set loader_path when targeting python, and leave it alone otherwise. Or, if enough other things have been addressed in OTIO that setting the loader_path is no longer required...

Maybe something like:

if(OTIO_PYTHON_INSTALL AND APPLE)
    set_target_properties(opentimelineio PROPERTIES 
        INSTALL_NAME_DIR "@loader_path"
        MACOSX_RPATH ON)
endif()

Although that would have the same problem if Python is enabled when building tlRender or other C++ apps.

Maybe for now I'll modify the tlRender CMake scripts to build OTIO static by default. That way everything should work OK when Python is disabled (which is the default).

For OTIO, maybe two sets of libraries need to be built? One for use by Python with @loader_path set, and a second for use with C++ with the normal path stuff?

My personal opinion is to prefer static linking. OTIO doesn't have any global mutable state, so there's little advantage to dload, and no requirement for it. We have just moved away from an Uber build in OTIO, where we tried to, in one go, build out for Python and C++ dev. Now we are taking the approach of build and install into python, and if you are interested in C++, that's a target you should do a distinct build for. The shared dynamic world is just too fragmented today! I think the rise of things like Docker just highlight that things kinda just didn't work out.

I like your suggestion of tlRender going with OTIO static linkage. I'm statically linking tlRender and OTIO already anyway, the fewer dylib's the easier/less confusing my life is :)

I checked in a change to build OTIO as static in the super build, now all of the dependencies are built static where the licenses permit.

I think the rpath stuff still needs more work though, for some reason the Qt examples are not being linked properly in the install directory.