On Sun, 22 Jan 2012, Michael Friedrich wrote:
> is it now mysql5? i don't recall exactly where 5.x was the minimum
> requirement, but there was some (maybe libdbi as is).
Yes, MySQL 5 is a prerequisite now due to the requirement of
the "ON DUPLICATE KEY" syntax. MySQL 4 will fail abjectly which
was the primary reason for updating my SPARC system at home to
that version.
Making matters worse, it looks like there are code dependencies
in the dbutils code that may pin things at 5.0. I tried getting
5.5 going at work and was completely thwarted.
> tbh i haven't checked that define lately. thanks for analyzing though.
You're more than welcome. During part of my analysis I did a
side-by-side check of ido2db vs ndo2db and that's what pointed up
the global use of "dbuf" in idoutils. Whether this is wise or not
may be left as an exercise for the reader.
>> commenting out a debug statement at line 1510 (not the best avenue,
>> I know, and I'll come up with something beter),
>
> it does not hurt to do so. many of those debug statements happened
> because on the origin ndoutils code you failed to get the design and
> possible cause of errors.
One of the things that bit me is that the code can be tickled
by virtue of what level of debugging is defined in ido2db.cfg, and
this may well be able to cause distress for folks on other platforms.
I've not tried it on Intel hardware, so I cannot say for sure, but
a null pointer is a null pointer no matter what you're running.
> preferred method is a git patch against current master.
>
> https://wiki.icinga.org/display/Dev/Developer+Guidelines#DeveloperGuidelines-Patches
I'll give that a read.
>> By the by, all the work was done on gcc 2.95.3, so that means
>> that I wasn't staring at a compiler error.
> as mentioned before, i got some issues before with it, so i am not
> entirely convinced by such errors if the compiler isn't a possible cause.
> but i am happy to see you fiddling with it and i'd be happy to have you
> with a sparc platform around - also to test future releases on git.
I'm a bit of a compatibility geek, mainly because I date to a time
when there were many more platforms available than Intel and SPARC. I
have several of these floating around, and have found that my striving
to be compatible across many architectures and compilers tends to keep
one's code very clean.
> if you got any special hints for other sparc users out there, feel free
> to write something onto the icinga community wiki as well - the howto
> space is waiting :)
Interestingly, I really don't have many "special hints". From my
experience, most environments just "do the right thing" if the code
is clean and well designed. I'm a "compile from scratch" sort of guy,
but that's down to my background. I don't know if I could get Icinga
to build and run on some of my really "elder kit", but it might be
instructive as the compilers tend to produce very detailed diagnostics.
That said, if I come up with something useful I'll be happy to add
it.
Cheers!
+------------------------------------------------+---------------------+
| Carl Richard Friend (UNIX Sysadmin) | West Boylston |
| Minicomputer Collector / Enthusiast | Massachusetts, USA |
| mailto:crfri...@rcn.com +---------------------+
| http://users.rcn.com/crfriend/museum | ICBM: 42:22N 71:47W |
+------------------------------------------------+---------------------+
------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
icinga-users mailing list
icinga-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/icinga-users
