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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
