[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Symbol-versioning a C++ library



On Thu, May 24, 2007 at 05:03:42PM +0200, Bas Wijnen wrote:
> 
> I have a library, which I want to package for Debian.  I felt it would
> be a good idea to use symbol versioning, since most of my programs (and
> in some cases other libraries) use it.  The library is written in C++,
> which seems to be a slight problem.  AFAIU the linker should be able to
> handle it, but I don't see how.

I am very interested in this topic as well, as a package I maintain,
scim, is also written in C++ and suffers from un-versioned symbol
collisions (bug #323216).

> Then I tried to give the whole shevek::fd class a different version by
> adding:
> 
> SHEVEK_2 {
> 	global:
> 		shevek::fd::*;
> };
> 
> (and some variations.)  That didn't work at all: it defines the version:
> 00000000 g    DO *ABS*  00000000  SHEVEK_2    SHEVEK_2
> But no symbol actually uses it.

Steve already said it's not possible to use un-mangled names, and he
definitely knows much more than I do.  But I have a piece of information
you may be interested.

The upstream author of scim worked for SUSE, and had to solve the save
symbol collision problem.  So he played with versioned symbols and had
the following snippet in the version script in the upstream source (the
src/libscim.version-script file in scim source package):

LIBSCIM_1.0 {
    global:
        extern "C++" {
            *scim::*;
        };

    local:
        *;
};

So what is new is the 'extern "C++" { ... }' part.  The upstream author
said it solved the symbol collision in some cases, but not every case.
This versioned symbol configuration is disabled by default in the
upstream releases, and Debian doesn't use it, so I have no idea how well
it works.  But you may want to give it a try and see.

Ming
2007.05.25



Reply to: