[Pkg-corba-devel] Symbol files in libomniorb

[Floris Bruynooghe]

On Thu, Mar 20, 2008 at 01:36:15AM +0100, Thomas Girard wrote:
> On Mon, Mar 17, 2008 at 11:22:21PM +0000, Floris Bruynooghe wrote:
> > (Actually both the old and new symbol look the same once gone through
> > c++filt.  So I'm not really sure why they are different symbols.)
> 
> I have no idea why this occurs. What's annoying is that this is marked
> as a weak symbol, so another binary providing the very same symbol name
> could possibly override it. I really need to understand what a typeinfo
> is.

Accoring to [1] a typeinfo it's a data structure generated for
exceptions in C++.

> Two remarks:
>  1. it's not really easy to prevent export of symbols in C++. g++ has
>     introduced visibility in version 4.0[1] but I don't know whether
>     this technique could be applied to our case.

Again according to [1] it is possible.  You'd have to go throught the
entire library and figure out which parts you can hide though.  And
sometimes you might not be able to hide a symbol if it throws an
exception that passes out of the DSO.  AIUI it should be possible to
re-create exceptions in the public/exported symbol/class, but that
involves re-writing code instead of "just" writing a version script.

>  2. maybe this typeinfo is not dangerous: no binary references it.
>     Besides the compiler seem to decorate the method name with a mark
>     (00000000_1608068924 -> 00000000_9A1F662124) that changes in new
>     versions, so it's unlikely we get a name clash.

I'm not entirely sure why it decorates it with a mark.  But supposing
the exception is expected to be caught in another DSO this could be a
problem since suddenly it's a different exception!  This makes me
assume that these typeinfo's are not actually meant to go outside of
the DSO otherwise someone must have had trouble with this already.

> > Anyways, I think this means we don't need an ultra-scrict dependency
> > on python-omniorb and omnievents.  But it also means we shouldn't be
> > including the symbol files since [1] does discourage that when private
> > symbols are exported.  From grepping for libtool in the source tree it
> > doesn't look like libtool is used, so we can't easily exclude the
> > symbols as suggested.  Maybe we should raise this with upstream?
> 
> Possibly. Is there a lot of private symbols? Was the difference
> generated by dpkg-shlibdpes big? Could you please store it in a public
> place so that we can have a look at it later?

There are a lot of symbols, no idea how many of these are supposed to
be private (given how many symbols there are I really hope the vast
majority are private).  I've put the symbol files on the pkg-corba
website under the symbols/ directory [2].

Lastly mole claims the symbol files need to be different for all the
arches for libcos4-1 and libomniorb4-1.  Mole didn't have these symbol
files yet when I started looking at this (or I failed to find them) so
I didn't know this.  Not really sure what influence this will have,
I can only hope that the symbols differing will appear to be private
symbols but I don't know (I'm not even sure when/why a symbol differs
on arches right now).


Regards
Floris


[1] http://people.redhat.com/drepper/dsohowto.pdf
[2] http://pkg-corba.alioth.debian.org/symbols/

-- 
Debian GNU/Linux -- The Power of Freedom
www.debian.org | www.gnu.org | www.kernel.org