On Aug 1, 2011, at 10:02 AM, Bjoern Michaelsen wrote: > On Mon, 1 Aug 2011 08:42:21 +0200 > Stephan Bergmann > <stephan.bergmann.secondary-gM/ye1e23mwn+bqq9rb...@public.gmane.org> > wrote: >> 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.
OK, I see. >> 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. And I would create the symlinks in the solver explicitly, anyway, not via ldconfig. ldconfig is imprecise, in that it takes a whole directory as input; and you would want to be able to link against a lib as soon as it is built, so would call ldconfig multiple times on $OUTDIR/lib (right?), which sounds like a bad idea in a parallel build. -Stephan _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
