Thanks for the quick responses Dave and Dejan. Dejans suggested fix for the
structure worked.
I am compiling with SunStudio11 and I can see that is not going to work. I will
see about getting gcc loaded on the system. I think we have 3.3 and 4.0
somewhere about.
Solaris 10 is an impressive OS, more people should try it.
Thanks for the help.
Ken
>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
