cyrus-sasl2: FTBFS (ppc64): /usr/bin/ld:Versions:3: syntax error in VERSION script

Henrique de Moraes Holschuh hmh at debian.org
Tue Oct 24 11:59:04 UTC 2006


On Tue, 24 Oct 2006, Andreas Jochens wrote:
> ppc64 would need the same symbols as the other architectures.

What is there in SASL is a basic ugly hack, because we don't know which
symbols *cannot* be versioned in the ABI for each arch.  Those are not stuff
from SASL, but rather internal symbols used by the linker (from my limited
understanding of the issue).

> However, it is difficult to get the same list of symbols as on other 
> architectures from the output of the nm utility because of a peculiarity 
> in the ppc64 object format they are not labelled with a T (Text segment) 
> but with a 'D' instead. There are also other symbols marked with a 'D'
> so it is not enough to simply grep for 'D' instead to 'T'.

With a list of what cannot be versioned, we could drop the use of nm on
ppc64.

> There are not that many packages which use versioned symbols. The ppc64 

Those are critical packages, and the plans are to add versioning to a great
deal more libraries as time goes on (basically, anything that is a direct or
indirect dependency of a nss-switch module *must* be versioned).  That's why
I think ppc64 needs a good answer for symbol versioning, you -will- need it.

> Symbol versioning seems to work very well for these packages, especially
> for the db4.x packages. This can be seen from the fact that the etch 

Can you look at those packages and check if whatever they do to get symbol
versioning would work for sasl in ppc64?  As long as the symbols get
versioned, changing how we do it in sasl would not be a problem.

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh



More information about the Pkg-cyrus-sasl2-debian-devel mailing list