Apologies all round - a typo in my earlier mail made this thread
even more confusing than it needed to be.
libpcp_pmda.so and the pmcd DSO agent are as they always were,
no plans to change that. What we do have now is this libpcp_pmcd
library... this turned out to be required on Windows. It contains
the pmcd internal symbols (code+data) that need to be visible to
both the pmcd binary and the pmcd DSO PMDA - on Windows you cannot
link a DSO to symbols from a binary, as we do on all the other
platforms.
Initially I made this new lib a shared library on all platforms,
but I later reverted that - its now a static library (everywhere
except on Windows) which pmcd links with, and the symbols are
resolved as they always were, directly from pmcd's address space,
by the pmcd DSO PMDA.
Sorry for the confusion!
cheers.
--
Nathan
On Wed, 2008-08-13 at 20:43 +1000, Max Matveev wrote:
> On Wed, 13 Aug 2008 20:25:25 +1000, Ken McDonell wrote:
>
> kenj> It is not libpcp_pmda.so that is the problem.
> kenj> It is libpcp_pmcd.so. It is clearly installed here
>
> kenj> ls -l /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so
> kenj> -rw-r--r-- 1 root root 19696 2008-08-12 16:43
> /var/lib/pcp/pmdas/pmcd/pmda_pmcd.so
>
> This is different - no? One is libpcp_pmcd.so, the other is
> pmda_pmcd.so? And the former looks like Nathan's invention - I don't
> get it on SGI's pcp-open.
>
> kenj> writev(2, [{"/usr/lib/pcp/bin/pmcd", 21}, {": ", 2}, {"error while
> loading shared libra"..., 36}, {": ", 2}, {"libpcp_pmcd.so", 14}, {": ", 2},
> {"cannot open shared object file", 30}, {": ", 2}, {"No such file or
> directory", 25}, {"\n", 1}], 10/usr/lib/pcp/bin/pmcd: error while loading
> shared libraries: libpcp_pmcd.so: cannot open shared object file: No such
> file or directory
> kenj> ) = 135
>
> max
|