Hi Stephan, On Mon, 1 Aug 2011 08:42:21 +0200 Stephan Bergmann <stephan.bergmann.second...@googlemail.com> wrote: > What do you mean with "BFS" here?
"build from scratch" > 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. Right, but extensions would not be run against the solver, but against an installation (where I suggested one needs to keep symlinks anyway). The suggestion was: - keep no SONAME or libuno_salhelpergcc3.so (unversioned) in solver and installation - still generate symlinks in installation so that in a installation (but not in solver), both libuno_salhelpergcc3.so and libuno_salhelpergcc3.so.3 are visible. > (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.) no. > 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. I came to the same conclusion: While the other scenario might work, it will end up like a evil genius dialog in the end: "But why did you do this?" -- "Because I can!". Thats not a good reason in itself. But maybe even the symlinks do not need to be manually declared and created in solver. To follow the conventions of the host system calling "ldconfig -n $OUTDIR/lib" after installing and before using the lib should be enough. However, experimenting with this does not seem to create an unversioned symlink. I created a dir with a few random libs: libxml2.so.2.7.8 (SONAME:libxml2.so.2) libcairo.so.2.11000.2 (SONAME: libcairo.so.2) libuno_salhelpergcc3.so.3 (SONAME: libuno_salhelpergcc3.so.3) and got: libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so.3 libxml2.so.2 -> libxml2.so.2.7.8 libcairo.so.2 -> libcairo.so.2.11000.2 so it does not create symlinks for the unversioned so (although those are quite common in /usr/lib here). For fun I move the lib libuno_salhelpergcc3.so.3 to libuno_salhelpergcc3.so and got: libuno_salhelpergcc3.so.3 -> libuno_salhelpergcc3.so (changed) libxml2.so.2 -> libxml2.so.2.7.8 libcairo.so.2 -> libcairo.so.2.11000.2 Which does not make me happy either. So I guess we need to create the symlinks (at least the unversioned ones) manually indeed. Best, Bjoern -- https://launchpad.net/~bjoern-michaelsen _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice