Anton, Thanks a lot for filing the bug. We would like to take care of it before Friday.
Regards Mohan On Sat, 2011-10-01 at 11:48 +0400, Anton Pak wrote: > Ed, > > Thank you for try! > > I created bug ticket #3416581 for the issues. > Fixes for issues #2, #6, #7 have been added in trunk (rev. #7361). > Could you check it? > > For issue #5 I created separate bug ticket #3416584. > Mohan, could you set right group for it? > > Strange, my FreeBSD-8.2 copy had had no issues with compilation. > > Anton Pak > > On Sat, 01 Oct 2011 04:39:07 +0400, Ed Maste <[email protected]> wrote: > > > I just took at the latest svn trunk to investigate building on FreeBSD > > again, and here are my notes relative to my last try. My testing is on > > FreeBSD 9. > > > > On Mon, Feb 14, 2011 at 09:51:57PM -0500, Ed Maste wrote: > > > >> I'm doing an initial investigation into porting OpenHPI to FreeBSD, and > >> have a couple of observations so far. > >> > >> 1) GNU configure > > > > Fixed, thanks. > > > >> 2) DST_* conflict > >> > >> In plugins/snmp_bc/snmp_bc_time.h there's an enum with members DST_NONE, > >> DST_USA, etc. These conflict with #DEFINEs of DST_NONE, DST_USA and the > >> like in FreeBSD's <sys/time.h> include. > > > > This problem still exists. I can't see how these enums (in > > plugins/snmp_bc/snmp_bc_time.h) are actually used. I prefixed > > each with an _ to let it compile. > > > >> 3) PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP not defined. > > > > Fixed. > > > >> 4) Unknown assembly pseudo-op .weakref > > > > This was a local issue on my end. > > > > 5) HOST_NAME_MAX in plugins/ilo2_ribcl/ilo2_ribcl.h > > > > bits/local_lim.h seems to be a Linuxism. As a workaround I just > > deleted the #include and added #define HOST_NAME_MAX 255 for now. I'm > > not sure at the moment what the right change is; in limits.h we have a > > #define _POSIX_HOST_NAME_MAX 255 > > > > 6) log2 conflict in plugins/ipmidirect/ipmi_sensor_factors.cpp > > > > Older versions of FreeBSD did not have log2(), 8.3 and 9.0 will and this > > conflicts with the local definition in ipmi_sensor_factors.cpp. > > FreeBSD defines __FreeBSD_version in sys/param.h and this can be used > > for conditionals to address this - e.g. > > > > #include <sys/param.h> > > #if __FreeBSD_version < 802502 > > static double log2( double val ) > > { > > return log( val ) / M_LN2; > > } > > #endif > > > > The values are documented at > > http://www.freebsd.org/doc/en/books/porters-handbook/freebsd-versions.html > > for example, > > 802502 March 6, 2011 8.2-STABLE after merging log2 and log2f into libm. > > > > 7) sockaddr_in in openhpid/server.cpp > > > > To obtain sockaddr_in I had to add > > > > #include <netinet/in.h> > > > > > > > > Thank you for working to make OpenHPI portable. > > > > -Ed > > > > ------------------------------------------------------------------------------ > > All of the data generated in your IT infrastructure is seriously > > valuable. > > Why? It contains a definitive record of application performance, security > > threats, fraudulent activity, and more. Splunk takes this data and makes > > sense of it. IT sense. And common sense. > > http://p.sf.net/sfu/splunk-d2dcopy2 > > _______________________________________________ > > Openhpi-devel mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/openhpi-devel ------------------------------------------------------------------------------ All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 _______________________________________________ Openhpi-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/openhpi-devel
