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

Andreas Metzler ametzler at downhill.at.eu.org
Sun Oct 22 07:05:57 UTC 2006


Hello,
Fullquote, as this goes to the mailinglist.

On 2006-10-21 Andreas Jochens <aj at andaco.de> wrote:
> On 06-Oct-21 10:55, Andreas Metzler wrote:
>>> gcc -shared  .libs/auxprop.o .libs/canonusr.o .libs/checkpw.o .libs/client.o .libs/common.o .libs/config.o .libs/external.o .libs/md5.o .libs/saslutil.o .libs/server.o .libs/seterror.o .libs/dlopen.o .libs/plugin_common.o  -ldl -lresolv  -Wl,--version-script=Versions -Wl,-soname -Wl,libsasl2.so.2 -o .libs/libsasl2.so.2.0.19
>>> /usr/bin/ld:Versions:3: syntax error in VERSION script
[...]
>> Could you please post the contents of lib/Versions after the failed
>> build to the bugreport?

> # cat lib/Versions
> SASL2 {
>   global:
> };

> The problem is that the object format for ppc64 is different. This 
> causes the output of the 'nm' utility to be different too. The function
> names are not marked as 'T' (text segment) as on most other 
> architectures so that the grep for " [Tt] " fails and the lib/Version
> script is basically empty. 

> This is not a bug in nm because the object format is really different 
> and the functions are not in the text segment but accessed indirectly
> on ppc64.

> The current procedure to create the lib/Versions script is simply not
> architecture independent and fails at least for ppc64.

> I could not yet find a filter condition which selects exactly the same
> symbols on ppc64 as on other architectures from the nm output.

I have seen that there are more similar bugs, e.g.
http://bugs.debian.org/354809 in which Florian Weimer says
| That's because ppc64 uses function descriptors.  It would probably
| make sense for binutils to mostly hide this distinction (unless there
| is a compelling reason not to do it).
| 
| > I am not an object file format expert at all, but I would take this 
| > as an indication that the current method of parsing of the nm output 
| > to create the Versions script is not really portable.
| 
| I still think this should be addressed in nm.

> The ppc64 port seems to work fine without using any versioning. Is it
> really necessary to use versioning for cyrus-sasl2?

Hello,
imho yes, for two reasons:
#1 libsasl2 is built with versioned symbols in sarge. Simply removing
them breaks binary compability, stuff built against lib+versym won't
work with the new version without versioned symbols.

#2 Sasl ends up in *many* applications directly or via libldap2 (e.g.)
and can also be pulled in by NSS. So if sasl changed its soname again
there _will_ be loads of packages temporarily (i.e. until we have made
te full transition) linking against both versions, and they will break
randomly due to symbol clashes.
cu andreas
-- 
The 'Galactic Cleaning' policy undertaken by Emperor Zhark is a personal
vision of the emperor's, and its inclusion in this work does not constitute
tacit approval by the author or the publisher for any such projects,
howsoever undertaken.                                (c) Jasper Ffforde



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