[Pkg-corba-devel] Symbol files in libomniorb
Floris Bruynooghe
floris.bruynooghe at gmail.com
Mon Mar 24 18:18:57 UTC 2008
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
More information about the Pkg-corba-devel
mailing list