Hi,
On Mon, Feb 25, 2008 at 10:18:42AM +0000, David Lee wrote:
> 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?
If it's rewritten as
static GSourceFuncs Gmain_timeout_funcs = {
Gmain_timeout_prepare,
Gmain_timeout_check,
Gmain_timeout_dispatch,
};
then it should have the same meaning. I've seen such a notation
before, but have no idea whether it's gnuism or not. It's about
initializing members of a struct, i.e. the ids before colon are
names of the struct members.
Thanks,
Dejan
> 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
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
