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+bqq9rb...@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 _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice