The only time I’ve had problems is when a plugin pulls in a shared lib that 
conflicts with another plugin which was built against a different version of 
the same shared lib, sometimes indirectly.  Often the order that the plugins 
get loaded can affect whether a clash occurs.
It’s a kinda-similar problem solved by static linking, but not really Nuke’s 
fault.

-jonathan


On Sep 25, 2014, at 10:38 PM, Nathan Rusch <[email protected]> wrote:

> Interesting... I don’t think anyone has ever mentioned that around here, so 
> thanks for the heads-up. I feel like I’ve run into symbol collision issues in 
> the past, but I may be misremembering or thinking of something else.
>  
> -Nathan
> 
>  
> From: Jonathan Egstad
> Sent: Thursday, September 25, 2014 10:58 AM
> To: Nuke plug-in development discussion
> Subject: Re: [Nuke-dev] Bundling libraries with a plugin?
>  
> You shouldn’t need to be too careful about hiding the symbols since Nuke 
> doesn’t load plugins with RTLD_GLOBAL so the plugin symbols shouldn’t pollute.
> At least that’s been my experience, your mileage may vary….  ;)
>  
> -jonathan
>  
> On Sep 25, 2014, at 9:22 AM, Nathan Rusch <[email protected]> wrote:
> 
>> Compile your dependencies as static libraries and link your Nuke plugin 
>> against them. For the dependencies, I would recommend either compiling them 
>> in custom namespaces to avoid potential symbol collisions with other code 
>> (if the build supports that), or compiling your Nuke plugin with all symbols 
>> hidden except the ones needed for the Nuke plugin interface.
>>  
>> -Nathan
>> 
>>  
>> From: Haarm-Pieter Duiker
>> Sent: Thursday, September 25, 2014 9:05 AM
>> To: Nuke plug-in development discussion
>> Subject: Re: [Nuke-dev] Bundling libraries with a plugin?
>>  
>> Are .bundle folders allowed to for Nuke plugins like they are (required) for 
>> OFX plugins?
>>  
>> HP
>>  
>> On Thu, Sep 25, 2014 at 8:56 AM, Paul Miller <[email protected]> wrote:
>> On 9/25/2014 10:54 AM, Haarm-Pieter Duiker wrote:
>> Hello,
>> 
>> Is there a best-practice for shipping plugins that need to be bundled
>> with libraries? I'm working on a plugin that needs to compile a set of
>> libraries with flags specific to the plugin. Those libraries will likely
>> exist in the user's system lib areas compiled with different flags,
>> against different runtimes, etc.. The goal is to be able to ship a
>> bundled package of plugins + libraries to end users that 'just works'.
>> 
>> I'd recommend putting your dependent libraries in your plugin Bundle along 
>> with your plugin, and load them dynamically if at all possible.
>> 
>> _______________________________________________
>> Nuke-dev mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>>  
>>  
>> _______________________________________________
>> Nuke-dev mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
>> _______________________________________________
>> Nuke-dev mailing list
>> [email protected], http://forums.thefoundry.co.uk/
>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
> 
> 
> _______________________________________________
> Nuke-dev mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
> _______________________________________________
> Nuke-dev mailing list
> [email protected], http://forums.thefoundry.co.uk/
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev

_______________________________________________
Nuke-dev mailing list
[email protected], http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev

Reply via email to