[Pkg-corba-devel] Symbol files in libomniorb
Thomas Girard
thomas.g.girard at free.fr
Thu Mar 20 00:36:15 UTC 2008
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
More information about the Pkg-corba-devel
mailing list