symbol versioning of private libraries builds

[simo]

On Fri, 2010-12-10 at 23:56 +1100, tridge at samba.org wrote:
> Hi Metze,
> 
>  > For that's not a valid setup, all components have to use the system talloc
>  > in that case.
> 
> but we have no way to enforce that, and I suspect it will happen. 

In this case the best option is to abort immediately at application
startup.
Anything else is begging for obscure errors or crashes later on an big
headaches.

> It has a much higher chance of working with the current setup than
> with the proposed patch.

Chance is not something you want to rely on, I am afraid.

>  > But for other libraries without impact on the whole application, we
>  > should make sure that we only use symbols from the private version
>  > of the library, instead of taking the old symbols from the system
>  > library and only the new symbols from the private one.
> 
> I don't think it will do that, but perhaps we could write a test to
> see what happens?

This is exactly what happens. It's how dynamic linking works.

>  > For libraries like tdb or ldb it's ok, if one component uses the system tdb
>  > to open component1.tdb while component2 uses the private one to access
>  > component2.ldb.
> 
> and it's also fine if they both use the private implementation, which
> I think is what would happen.
> 
> I don't think talloc is the only 'special case' btw. I think tevent
> has the same issues.

Yes, tevent would have the same issues, and tdb too.

You never want to use the same symbols from 2 versions of a library
within the same code. Aborting as soon as this happens is a much better
idea than trying to workaround it.

The only other sane way to explicitly use conflicting libraries is to
have entry points remapped at load time using dlopen() with RTLD_LOCAL
and then dlsym() to lookup symbols and assign them to non-conflicting
names within the application.

Simo.

-- 
Simo Sorce
Samba Team GPL Compliance Officer <simo at samba.org>
Principal Software Engineer at Red Hat, Inc. <simo at redhat.com>