[Pkg-corba-devel] Symbol files in libomniorb

[Thomas Girard]

Hello Floris,

On Mon, Mar 17, 2008 at 11:22:21PM +0000, Floris Bruynooghe wrote:
> As you probably have seen I've committed symbol files for the omniorb
> libraries in the 4.1.1 version.  When trying to upgrade this to the
> 4.1.2 version I ran accros the problem that a few symbols disappeared,
> which should not be allowed.  The problem is that I suspect that the
> missing symbols are internal, e.g.
> 
> - _ZTIN83_GLOBAL__N_.._.._.._.._.._src_lib_omniORB_dynamic_valueFactory.cc_00000000_1608068924valueFactoryTableTrackerE at Base 4.1.1
> +#MISSING: 4.1.2-1# _ZTIN83_GLOBAL__N_.._.._.._.._.._src_lib_omniORB_dynamic_valueFactory.cc_00000000_1608068924valueFactoryTableTrackerE at Base 4.1.1
> + _ZTIN83_GLOBAL__N_.._.._.._.._.._src_lib_omniORB_dynamic_valueFactory.cc_00000000_9A1F662124valueFactoryTableTrackerE at Base 4.1.2-1

Eh, this looks like morse code :-)

(and)

> Today I discovered c++filt which makes interpreting the symbols a
> whole lot easier :-).

`objdump -o -T -C' or `nm -C -D' are quite useful too when it comes to
C++ symbols in shared libaries.

>                        Grepping around the omniORB source confirms
> that the missing symbols are internal, they don't even show up in the
> "internal/" direcotry of the include files only somewhere in src.

That's great news! Indeed on the example you provided it's related to
a class that is fully defined and used whithin a single compilation
unit.

> (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.

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.

 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.

> 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?

> In the mean time I think it's best to remove the symbol files again
> from omniorb4 and continue working without them until the exporting of
> private symbols is sorted upstream.

Agreed, we don't need symbols right now. (And they are available from
Mole[2] if we need them.)

> As an aside.  While figuring this out I discovered we should
> preferably include the soname of -DEV packages in the name[2].  I
> think that would give us libomniorb4-1-dev, instead of
> libomniorb4-dev.

There's no consensus on this. Some prefer including the SONAME, others
don't. I think it's better no to, because:
 1. we only support a single omniORB version in the archive
 2. it makes reverse dependencies easier to rebuild when our SONAME
    changes.

> I also don't really know why libcos has it's own package (it's -DEV
> has no header files btw).

There are header files in libcos4-dev: the stubs generated for
common CORBA services, in /usr/include/COS.

>                            I rember reading somewhere that ideally
> each lib has it's own package in Debian, in case of soname bumps IIRC.
> But libomniorb4-1 has 5 libraries in it anyway.  Or did they sneak in
> over the life of the package (I didn't find any hints in the
> changelog)?

Yes, ideally. But these libraries are omniORB core libraries, and they
are supposed to work together. Having a separate package for each
library is a maintenance nightmare and makes transition to new versions
harder. Other packages in Debian provide multiple libraries, e.g.
kdelibsc2a.

Regards,

Thomas

[1] http://gcc.gnu.org/wiki/Visibility
[2] http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libomniorb4-1