pcp
[Top] [All Lists]

Re: Multi-archive Contexts: Some PCP Tools Lost in Time

To: Ken McDonell <kenj@xxxxxxxxxxxxxxxx>
Subject: Re: Multi-archive Contexts: Some PCP Tools Lost in Time
From: fche@xxxxxxxxxx (Frank Ch. Eigler)
Date: Tue, 16 Feb 2016 17:59:45 -0500
Cc: pcp@xxxxxxxxxxx
Delivered-to: pcp@xxxxxxxxxxx
In-reply-to: <56C395AF.1030306@xxxxxxxxxxxxxxxx> (Ken McDonell's message of "Wed, 17 Feb 2016 08:33:35 +1100")
References: <56C3608E.9090404@xxxxxxxxxx> <y0mvb5oa323.fsf@xxxxxxxx> <56C37828.10007@xxxxxxxxxx> <20160216194348.GC2398@xxxxxxxxxx> <56C395AF.1030306@xxxxxxxxxxxxxxxx>
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)
kenj wrote:

> [...]
> I think all of
> - pmlogdump
> - pmlogcheck
> - pmlogrewrite
> should / could be constrained to operate on a single archive at a time.
> [...]

(Yeah, maybe.)

> Would that make life easier?

Not sure; I'll defer to brolley for the more definitive word.  But
from first principles, one problem here is that the libpcp ABI
includes -some- data structure definitions, like _pmContext and its
connected bits.  Old binaries that traverse those data structures were
compiled against a previous <impl.h>, and could crash or whatever if
run against libpcp.so that has the changes -- whether or not they
happen to be operating on a multi-archive.

It sounds likely that the apps that rely on impl.h internals (why is
that file installed anyway?) may be the same ones that that we can
detect & disable with a symbol-versioning hack such as a dummy 
__pmHandleToPtr() { return 0; } function.


- FChE

<Prev in Thread] Current Thread [Next in Thread>