On Fri, 22 Feb 2008 [EMAIL PROTECTED] wrote:
> Well I got version 2.1.3 of Heartbeat and tried that on Solaris 10 and
> it had more issues then 2.0.7.
Firstly, great to see a Solaris person using heartbeat; welcome aboard!
> All have been in lib/clplumbimg so far and most were;
> undefined symbols __FUNCTION__
> void function can not return value
>
> which are easy to fix.
Hold on...
For many years, the heartbeat source code has compiled, built (and even,
in parts, run) reasonably well on Solaris. And we've tried to make sure
that the code is portable in principle (and to Solaris in particular).
So a systematic problem such as that you describe suggests a deeper issue,
so let's be cautious about rushing a fix.
A guess: What compiler are you using? Although we have made the effort to
make the code portable (in principle) to any UNIX-like platform (including
Solaris in particular) we have, for pragmatic reasons, assumed that the
compiler is some version of "gcc". If you are using non-gcc (e.g. Sun's
Studio) then you may get problems.
And other things may crawl out of the wordwork (e.g. there may be some
GNU-make-isms).
Yes, we aim strongly for portability to any UNIX-like platform. But at
present heartbeat still assumes the availability of GNU tools (gcc, make)
on that platform.
Let's take two different aspects:
1. For you to get something working, then switch to gcc.
2. To get it working under Sun's compilers, then we'll be happy to accept
patches. But before you spend too much effort on detailed patches,
discuss the principles over on the "linux-ha-dev" list, so that we can
ensure that the principles behind those patches are optimal. (One of the
principles is to point the compiler towards "ANSI-C" flavour.)
> It does not seem that REBOOT1ARG gets set correctly.
That's a known problem with some new code that appeared shortly before
2.1.3 was released. About a week ago, I fixed this in the mercurial
repository. So future releases should be OK.
For the moment, fudge it. Or if you're happy to use the "development"
branch of the repository, use that. Or I could send you the patch.
> The one that has me stopped is in GSource.c
>
> static GSourceFuncs Gmain_timeout_funcs = {
> prepare: Gmain_timeout_prepare,
> check: Gmain_timeout_check,
> dispatch: Gmain_timeout_dispatch,
> };
>
> Not sure what to do with that.
Wow! I've never seen that sort of syntax before. And I've just checked
with two highly experienced C programmers here... they, too, have never
seen such syntax.
Weird. That must be some sort of gcc-specific code. (Or C++?)
Although my earlier statements mentioned that pragmatically we are 'gcc'
in practice, nevertheless we try to be ANSI-C in theory.
So my personal view is that that declaration should be rewritten to be
"standard" C. (Not gcc-specific, not C++, but goold old K&R+ANSI C.)
Pause... Let's check the K&R book, ANSI-C edition. Is this some sort of
bit-field? Even so, the book then goes on to warn about such things. So
even if this is, technically, ANSI-C, I doubt that it is "best practice".
Can someone briefly describe what that declaration is wishing to achieve?
Then we can set about understanding it and seeing if it can be made more
reliable.
Hope that helps.
--
: David Lee I.T. Service :
: Senior Systems Programmer Computer Centre :
: UNIX Team Leader Durham University :
: South Road :
: http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE :
: Phone: +44 191 334 2752 U.K. :
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
