Re: fun with libgal
On Wed, Jan 23, 2002 at 23:05:44 +0900, Junichi Uekawa wrote:
> linking statically against a library does not make everything work
I didn't claim it did. What it does is allow one to escape from having to
rebuild packages every time an API-unstable library changes its .so version
number (and then having to wait to see if that library will hold still for
long enough for it, and any packages depending on it, to propagate into
testing at all).
> For example, libgal seems to contain some translations, but gnumeric
> doesn't seem to have them.
> i.e. only the library is statically linked, not the data.
> So we have a broken package, which may or may not work because there is a
> missing depends on the data.
If you consider gnumeric broken, do file a detailed bug report.
> Unless you really know what you are doing,
I think I do. Gnumeric used to have a run-time dependency on a shared
libgal. This proved to be unworkable, and switching to linking it statically
against libgal proved to be the workable alternative.
> please don't link statically to a library, if a shared version is
In general, that's good advice. In the particular case of GAL, I disagree.
GAL is not intended to be API stable: it is essentially a rapidly changing
common code repository (primarily for Evolution and Gnumeric); API and code
that stabilise move into other libraries. IMHO it makes little sense at all
to have it as a dynamic library, in particular not as long as its maintainer
refuses to make the GAL packages so that different .so versions can be
installed simultaneously on one system. (See bug #107796)
Ziff Davis is so obviously biased to Microsoft in almost everything they
publish, that they might as well change their company name to MS-PRAVDA.
Darryl Householder commenting on extreme PC Week FUD