[Libreoffice] problems with scp2

[Stephan Bergmann]

On Jul 31, 2011, at 12:32 AM, Bjoern Michaelsen wrote:
> On Sat, 30 Jul 2011 10:45:03 +0200
> Stephan Bergmann
> <stephan.bergmann.secondary-gM/Ye1E23mwN+BqQ9rBEUg at public.gmane.org>
> wrote:
> 
>> No. While linking wants the unversioned libFOO.so (thanks to passing
>> them as -lFOO to the linker), running the unit tests wants the
>> versioned libFOO.so.3 (thanks to the SONAME).
> 
> Im glad to have told Matúš to put this on the ML, it deserves a more
> thorough investigation. ;)
> 
> Well, since gbuild as of now has no notion of versioned SONAMES or
> filenames(1), I assume the Matúš-migrated salhelper module would create
> a lib with name libuno_salhelpergcc3.so and no explicit SONAME (since no
> --soname switches are used). "readelf -a| grep SONAME" on it would
> return nothing. Given that, every library linked against that lib (in a
> BFS) would link against the (fallback) unversioned filename, and that
> would work fine in the build and out of it.

Hi Björn.

What do you mean with "BFS" here?

Generally, existing code (i.e., extensions) having a recorded dependency against libuno_salhelpergcc3.so.3 will no longer work if they do not find a file with that exact name.  (Or do you imply that, on Linux, the dynamic loader special cases this and would still be happy if it only found some libuno_salhelpergcc3.so?  I am not aware of that, and it would be Linux-only, probably not working on e.g. Solaris.)

> Using such a lib in the solver should not be a problem for the build.
> However, even if it would be easily possible to add the SONAME upon
> installation, it would be quite an ugly hack. So does it hurt to have
> unversioned/missing SONAMEs in the installation?

I strongly suggest to add SONAME support to gbuild.  For one, it is common ELF practice to use external versioning (i.e., via a trailing .so.X at a library's filename/SONAME) to discriminate among incompatible versions of a library.  And for another, we already use that external versioning scheme for the libraries that comprise the URE interface, and I see no reason to change that (causing incompatibility with existing code).

> Well, if we would symlink in the installation as before, old
> external clients wouldnt be hurt, as they still find their libs. But
> newly created external libraries would be created linking against an
> unversioned/missing SONAME (because they would fall back to the resolved
> filename). Would that hurt? Right now, from a practical point of view,
> I guess: no. No linux distro supports installing different versions of
> the product, let alone from different major releases. So if I am not
> mistaken, the benefit of versioned SONAMEs -- while being the Right
> Thing(tm) -- are mostly theoretical as of now.
> 
> Of course, the magic is all in the words "as of now" -- requirements
> might change. 

-Stephan