[Pkg-libburnia-devel] adding symbol files to the burn library packages

[George Danchev]

On Saturday 28 February 2009 23:41:46 Simon Huggins wrote:
> 'ello George,
>
> On Sat, Feb 28, 2009 at 07:57:00PM +0200, George Danchev wrote:
> > First, thank you for uploading the new upstream versions. Next, I
> > guess it would be a good idea to add symbol files to the library
> > packages. These are all under active development, so any symbols
> > appearing and disappearing from news upstream versions are quite
> > possible, though I believe the authors perform quite sane library
> > management. I already have experience with adding symbols to the
> > sofia-sip library package, so if you want me I can explain and perform
> > the process. In short, it is almost about grabbing symbols diff from
> > autobuilders for the architectures we don't have at hand and enforcing
> > a check level of dpkg-gensymbols (-c option, default is fine I think).
>
> I think it's a good idea.  I don't have any experience of doing it but
> if you want to provide/submit patches then do so.
>
> If you need a hand or have a link to docs that would be good.

the only decent docs I know of is dpkg-gensymbols(1) ;-)

Ok, here is a short introduction: Note that most libs have 
architecture-specific symbols. Fortunately, libburn4 produces 
arch-independant symbols:

http://qa.debian.org/cgi-bin/mole/seedsymbols?pkgname=libburn4
So we can safely grab it.

For libs with architecture-spacific symbols sets, the symbol files could be 
added this way. Let say we have built the libraries on i386 architecture and 
object files are in place (you can try that yourself even without cowbuilder 
chroot):

1) cowbuilder --update ; then --login --bindmount ...
(We need a crystal clear build environment in order to avoid getting symbols 
from accidenlty linked object files)

2) svn-buildpackage --svn-builder="dpkg-buildpackage -S"
(We need the source package only in build-area)

3) cd build-area/libburn && fakeroot debian/rules binary
(We need the object files in order to be able to get their symbols).

4) We are ready to extract the symbols now 
dpkg-gensymbols -plibbobcat2 -Pdebian/libbobcat2/ -Odebian/libbobcat2.symbols.i386

5) Move that debian/libbobcat2.symbols.i386 to trunk/debian, and don't forget 
to remove the debian revision from the lines, e.g. replace A.B.C-D with A.B.C 
to please lintian (would smooth library transitions).

6) upload and wait for autobuilders logs to grab diff from
We would need to upload empty symbols files foro architectures we don't have 
at hand, feed autobuilders, and then grab symbols diffs from their buildlogs. 

For example:
https://buildd.debian.org/fetch.cgi?&pkg=bobcat&ver=2.01.0-1&arch=s390&stamp=1235338491&file=log

See the diff below dpkg-gensymbols call. We grab that in order to patch 
debian/librarypackage.symbols.$ARCH.

Check levels enforcement: The purpose of dh_makeshlibs calling dpkg-gensymbols 
is to show you the symbols diff if any, i.e. if your object code symbols 
differ from these supplied in debian/package.symbols.$arch and to enforce the 
check level (-c option) if any have been given to override the default -c1, 
i.e. what to do when certain differences are in place... for instance missing 
symbols... the worst.

> On Sat, Feb 28, 2009 at 09:58:57PM +0200, George Danchev wrote:
> > Guys, it seems we will have another 'new upstream' upload soon.  The
> > symbol initiative still holds, but it is not justified to do it for
> > the packages currently in sid, but the forthcomming ones. Agreed?
>
> I thought you only got the benefit of symbols files if they analysed
> lots of old versions of the library and that the idea was the symbols
> file gave the first version that a particular symbol was in.
>
> So doing the work now still gets us that and then you do it continuously
> for new versions.

True, but see below.

> Is that not how it works?

That is correct.

> I don't quite get why another arch is needed but I don't know much about
> it.

Most of the time you need the other arch, since symbols are extracted from the 
object code for that particular arch and chances are great that we got arch 
specific symbol set.

Let me know if you have any questions and let's see if I can find any time 
this weekend to complete the above procedure for one package at least. 

-- 
pub 4096R/0E4BD0AB 2003-03-18 <people.fccf.net/danchev/key pgp.mit.edu>