[fpc-pascal] linux: should we hard-code versioned or unversioned shared libraries in our apps?

[Henry Vermaak]

On 15/08/12 13:43, Mark Morgan Lloyd wrote:
> 
> I do agree with Graeme's position though: a -dev is described as
> containing files for developers, and it should not be necessary for a
> non-developer user to start encumbering his system with .h files etc.
> What's more, part of the reason that I've had to create symlinks
> manually in the past is because things like (if I recall correctly)
> OpenOffice's interface to PostgreSQL require libpq.so without declaring
> -dev as a prerequisite... which rather reinforces my position that this
> is a distro issue even if they prefer to disclaim it.

I'd say that it's the OpenOffice interface that's broken.  They
shouldn't link to a library that doesn't specify a version.  They need
to link to a specific version by using the naming conventions as Jonas
explained.  This is to protect yourself from api/feature breakage.
Linking directly to, e.g. libpq.so, is only o.k. if you can check the
version by means of some api, which the library needs to supply in all
the versions that exist - past, present and future.  Which is probably
what they're doing.  This isn't very good practice, in my opinion, but
can work.

If they really support multiple versions of libpq, then they will have
to try to dynamically link against all the versions they support.  This
won't be much more effort than checking the version in the first place.

Even on Windows some libraries are using names that reflect the version,
e.g. I link to some opencv libs, which are named
libopencv_{module}231.dll.  I suspect this is much less of a problem in
the Windows world, since library reuse isn't that common.

Henry