[Pkg-corba-devel] Symbol files in libomniorb

Floris Bruynooghe floris.bruynooghe at gmail.com
Mon Mar 17 23:22:21 UTC 2008


Hello

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

Althought -if they are indeed private- this will most likely work,
this isn't good.  A library should only export public symbols and keep
all others private[1].  And we can't even try to restrict the exported
symbols to exclude private symbols (guided by
include/omniORB4/internal/*.h) since both omniORBpy and omnievents use
some internal headers (and hence, I assume, private symbols).

This is rather rubbish I think.  AFAIK it means we should limit
python-omniorb and omnievents to the exact library version we compile
it with (and must always synchronise uploads) or we might get
unexpected breakage.  But as far as I understand currently it's the
only correct way to deal with it for now.

AIUI we should ideally convince upstream to not use private symbols in
omniORBpy and omnievents, and make those that are absolutely required
part of the public API/ABI -- with associated restrictions.  But it
would at least ensure sane libraries that won't break.


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.

I also don't really know why libcos has it's own package (it's -DEV
has no header files btw).  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)?


Thoughts?
Floris


[1] I'm sure I should be cite this...

[2] http://www.netfort.gr.jp/~dancer/column/libpkg-guide/libpkg-guide.html#id291895

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