Re: RFC: OpenLDAP and TLS/SSL
On Wed, 21 Aug 2002, Luca Barbieri wrote:
> This is an another problem that would be easily and compatibly solved by
> my ELF extension (until the library gets properly fixed upstream).
Yes and no. Versioned symbols are here NOW and can be used NOW, and they fix
the issue cleanly without drawbacks: they are as painful as a
do-it-only-once global soname increase (which is quite painful though).
It has the potential of encoding C++ ABI (or any other identifiers we need)
information as well, should that be desired. -Bsymbolic (your modified
version of it) cannot fix that.
> concept that symbol names must be *globally* unique, not just unique to
> filename and that they either put the version number in the symbol (e.g.
> sasl1_explode vs. sasl2_explode) and use #define's to keep source
> compatibility or they use GNU/Solaris versioned symbols.
Yes. We really should simply have *all* libraries using versioned symbols.
The version symbol "tag" could always be at least the library soname (i.e.
the ABI number, and library name).
Is there a reason for not doing the above? It's not like it would be
difficult to do (although it means a mass-recompile, but it certainly needs
not to be done all in one day...). We could just try to set a standard that
linux-based OSes *distributions* always versions its symbols with the ABI
soname, and that's it...
That won't fix the breakage caused by C++ compilers, unfortunately. The C++
ABI number would have to be added to the library versioning tag, too. It
can be done without changes to the linkers, by the makefiles [we just need a
way to query the compiling environment which stuff we should prefix/suffix
the symbol versioning with].
It's cleaner to just have another ELF field with the compiler ABI, and have
gcc and other C++ compilers for linux add that automatically...
> We should also alert upstream of this kind of problems _before_ new
> versions get released and binary compatibility makes them untouchable.
ABIs are not really upstream's responsability... unless it is a Linux-only
package, when upstream *might* take care of it, if they want to.
--
"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
Reply to: