On Wed, 24 Nov 2004, Stephen Przepiora wrote:
> Hello, I have noticed the pmcd pmda does not compile on windows and
> looked into it a little and found out it is because windows does not
> allow undefined references at compile time in shared libraries.
Yep, this is the correct diagnosis.
> Whereas in other os's the linker will patch everything up nice at
> runtime.
>
> While searching for a workaround, I came across this page:
> http://www.mail-archive.com/cygwin@xxxxxxxxxxxxxxxxxx/msg16806.html
>
> Which gives two work arounds:
>
> 1. Put the common symbols in a dll and link pmcd.exe and pmda_pmcd.dll
> to the new dll.
The problem with this approach is that the new "dll" needs to be in
a place where you can find it at build time and run time on all
platforms ... for *nix derivatives, this tends to pollute /usr/lib or
similar with something that is not really a library in the true sense.
> 2. Add a function to pmda_pmcd.dll and pass in pointers to the data:
> pmda_pmcd.dll
> int * ext_data;
> void set_ext_data(int * c) {ext_data = c};
> In dll, use *ext_data.
>
> pmcd.exe
> int data;
> set_ext_data(&data);
> in client, use data.
Unfortunately this won't work ... pmcd has to work without being linked
to pmda_pmcd.
I prefer a 3rd approach
- gather the data of shared interest into a struct in the pmcd src
- have pmcd arrange for this struct to be in a mmap()'d (e.g.
/var/tmp/pmcd.data)
- the pmda attaches to the mmap()'d shared memory
This is clean.
This is portable.
This would allow the pmcd pmda to be a daemon, not a ddl/dso (also
improves portability).
> Is any work being done on this?
No, I don't have the bandwidth to do this, but I'd be happy to help
someone else who wanted to make the change, review their patch and
get it into the official PCP source.
|