Date: prev next · Thread: first prev next last
2011 Archives by date, by thread · List index


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

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.