Re: [Libreoffice] problems with scp2

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@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