[prev in list] [next in list] [prev in thread] [next in thread] 

List:       linux-ha-dev
Subject:    Re: [Linux-ha-dev] Specfile, heartbeat/stonith dependency
From:       Michael Moerz <aon.912411198 () aon ! at>
Date:       2000-10-29 18:59:59
[Download RAW message or body]

Hi!

On Fri, Oct 27, 2000 at 08:21:09AM -0600, Alan Robertson wrote:
> Lars Marowsky-Bree wrote:
> > 
> > That is in fact broken. ;-) It should be linked dynamically, no?
> 
> Yes.   The only reason why it was linked statically was laziness, not
> design.  I linked it statically before I read the man page on how to produce
> a shared library.  On the other hand, the static part of the library isn't
> that big.  Most of the size is in the loadable libraries.
>
I'd say that static linkage is to avoid whenever possible. I can also
state that there are others out there having the same opinion about that
topic e.g. the debian distribution ( Since I think talking too much
about why's is off topic here, I point all people trying to convince
me better over to debian. There the "right" thoughts about that topic are 
covered ). So if the static linkage is hold on to, then heartbeat
will break with the debian policy and therefore the debian maintainer
would either have to fix this issue or to drop heartbeat out of main 
and put into contrib.

> It seems to me to be clearly a bug.  One of the reasons why its a bug is
> that the version of the library linked into heartbeat could be older or
> newer than the version loaded on the machine.  This could lead to
> incompatabilities between the static part linked into heartbeat and the
> dynamic part which has actually been loaded into /usr/lib/stonith.  These
> could result in crashes.
>
yeah, this is of course one of the major problems of static linking.

-- 
kind regards,
Michael Moerz

_______________________________________________________
Linux-HA-Dev: Linux-HA-Dev@lists.tummy.com
http://lists.tummy.com/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/

[prev in list] [next in list] [prev in thread] [next in thread]