Re: Symbol-based dependencies on shared libraries: some news
On Sat, 04 Aug 2007, Steve Langasek wrote:
> On Sat, Aug 04, 2007 at 10:41:25PM +0200, Raphael Hertzog wrote:
> > On Sat, 04 Aug 2007, Loïc Minier wrote:
> > > Do you strip the "well known symbols" you've seen on each arch so that
> > > one only has to specify the other symbols?
>
> > No, because they might change with the toolchain and we want to track that
> > properly...
>
> Why does it need tracking? If these symbols were to disappear that would
> be no loss, it shouldn't be relevant to the library ABIs at all. I think it
> would indeed be better to exclude these symbols from the list.
Somehow I always thought that the executables were using those symbols.
If that's not the case, and if they are only used by the internal
machinery (i.e. none of those symbols actually appear undefined in objdump's
output of a program), then I'll happily strip them from the symbols file.
That exclude list will still have to be maintained over the years I think
since the list will probably evolve.
I'm checking for example on a powerpc machine:
/bin/ls: file format elf32-powerpc
DYNAMIC SYMBOL TABLE:
10025168 DF *UND* 00000010 GLIBC_2.0 readlink
10025170 DF *UND* 00000154 GLIBC_2.0 getgrnam
1001136c g DF .text 0000003c Base _restgpr_18
10025178 DF *UND* 0000003c GLIBC_2.2 __fpending
10011444 g DF .text 00000014 Base _restgpr_31_x
1001138c g DF .text 0000001c Base _restgpr_26
100112f8 g DF .text 00000018 Base _savegpr_27
10011384 g DF .text 00000024 Base _restgpr_24
10011424 g DF .text 00000034 Base _restgpr_23_x
So it looks like those symbols are defined in each and every binary.
But the programs do not rely on the same symbols from the libraries.
Thus it seems fine to exclude them from the symbols files.
Cheers,
--
Raphaël Hertzog
Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/
Reply to: