Re: [Libreoffice] problems with scp2

Hi Stephan,

On Mon, 1 Aug 2011 08:42:21 +0200
Stephan Bergmann
<stephan.bergmann.secondary@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