https://github.com/imageworks/OpenColorIO/pull/209

OCIO_LINK_PYGLUE allows pyglue to skip python linking.  Default value is 'YES' (current behaviour).

PyOpenColorIO.so is not useful in apps unless the application already links to python, so it's not always necessary to additionally have the glue also link to a specific python lib. Doing so is potentially dangerous in some production environments, as it introduces a version dependency that may not be helpful.

It makes sense that by default you'd want the linking enabled (to pass rpmlint) but it's useful to be able disable it at build-time.

-- Jeremy

On Wed, Dec 21, 2011 at 1:59 PM, Jeremy Selan <jeremy...@...> wrote:

https://github.com/imageworks/OpenColorIO/pull/209

OCIO_LINK_PYGLUE allows pyglue to skip python linking.  Default value is
'YES' (current behaviour).

PyOpenColorIO.so is not useful in apps unless the application already links
to python, so it's not always necessary to additionally have the glue also
link to a specific python lib. Doing so is potentially dangerous in some
production environments, as it introduces a version dependency that may not
be helpful.

Hmm.. I already commented on github, but now having thought about it
for a second, maybe you can explain something for me since I'm
definitely not a programming expert (or really even a novice :)

So if another binary or library links against libPyOpenColorIO and
libPython.so then libPyOpenColorIO can inherit the symbols it needs
from the parent?

It makes sense that by default you'd want the linking enabled (to pass
rpmlint) but it's useful to be able disable it at build-time.

The only reason I created the patch to link against libpython.so was
because libPyOpenColorIO.so contains some symbols that is provides. Is
it possible to change something about the build so it doesn't run into
this problem in the first place?

Thanks,
Richard