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