1. Ocio-Dev
  2. Topics

Custom namespace specification and SONAMEs

Piotr Stanczyk <piotr.s...@...>
 

Hi All,

I am looking to build the core lib with the -D OCIO_NAMESPACE=foo option.  Whilst this builds just fine, I see that the SONAME is unchanged with the above.
So, how do you resolve ambiguities here? Should I be passing in the -D SONAME=foobar in here?

Any tips welcome - thanks

Piotr
Jeremy Selan <jeremy...@...>
 

Hmmm... I hadnt thought about passing an alternate soname to the build process, but it makes sense that you could need it for applications which load both a public and private version of OCIO.  

Can you share any more specifics about what you're trying to do? Either way, I'm happy to add a custom SONAME option (if it doesnt already exist).

For example, at SPI we build custom versions of the nuke OCIO plugins (so we can stay up to date with the public master repo), which link to our spi namespaced version of OCIO, and merely by registering our custom nodes first we havent had an issue.  I'm curious why we havent needed to worry about an alternate so name.

-- Jeremy



On Mon, May 6, 2013 at 4:27 PM, Piotr Stanczyk <piotr.s...@...> wrote:
Hi All,

I am looking to build the core lib with the -D OCIO_NAMESPACE=foo option.  Whilst this builds just fine, I see that the SONAME is unchanged with the above.
So, how do you resolve ambiguities here? Should I be passing in the -D SONAME=foobar in here?

Any tips welcome - thanks

Piotr


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@....
For more options, visit https://groups.google.com/groups/opt_out.
 
 
Piotr <piotr.s...@...>
 

Thanks Jeremy,

We use a 3rd party tool that is built against OCIO. Their recent release includes a custom namespaced OCIO build, but with no header file installation. The issue is that whilst they have namespaced their OCIO build with a prefix, the soname remains unchanged. This is quite possibly the worst scenario since our plugins (which also link against the same version of OCIO) fail to load as the symbols cannot be resolved by the linker.

We are thus wanting to build our own namespaced version of OCIO with a corresponding SONAME; at the moment I am testing a build with a
-D SOVERSION=LFL
option to the configuration.

Curious as to how others do it.

Cheers

Piotr



On Tuesday, May 7, 2013 8:43:42 AM UTC-7, Jeremy Selan wrote:
Hmmm... I hadnt thought about passing an alternate soname to the build process, but it makes sense that you could need it for applications which load both a public and private version of OCIO.  

Can you share any more specifics about what you're trying to do? Either way, I'm happy to add a custom SONAME option (if it doesnt already exist).

For example, at SPI we build custom versions of the nuke OCIO plugins (so we can stay up to date with the public master repo), which link to our spi namespaced version of OCIO, and merely by registering our custom nodes first we havent had an issue.  I'm curious why we havent needed to worry about an alternate so name.

-- Jeremy



On Mon, May 6, 2013 at 4:27 PM, Piotr Stanczyk <piotr...@...> wrote:
Hi All,

I am looking to build the core lib with the -D OCIO_NAMESPACE=foo option.  Whilst this builds just fine, I see that the SONAME is unchanged with the above.
So, how do you resolve ambiguities here? Should I be passing in the -D SONAME=foobar in here?

Any tips welcome - thanks

Piotr


--
You received this message because you are subscribed to the Google Groups "OpenColorIO Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ocio-dev+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

1 - 3 of 3