I'm doing an initial investigation into porting OpenHPI to FreeBSD, and
have a couple of observations so far.
1) GNU configure - one of the tests is using == for string comparison,
which works if /bin/sh is bash, but not if it's FreeBSD's sh. (I
suspect Debian and Ubuntu users will encounter this too, with /bin/sh
being dash.)
The fix is:
$ diff -purw acinclude.m4.orig acinclude.m4
--- acinclude.m4.orig 2011-02-14 21:15:51.000000000 -0500
+++ acinclude.m4 2011-02-14 21:16:10.000000000 -0500
@@ -137,7 +137,7 @@ AC_DEFUN([OH_CHECK_GCC],
} \
}'` \
- if test "$GCCVERSIONOK" == "OK"; then
+ if test "$GCCVERSIONOK" = "OK"; then
AC_MSG_RESULT(yes)
else
OH_CHECK_FAIL(gcc >= $1.$2.$3 is required to build OpenHPI)
@@ -200,7 +200,7 @@ AC_DEFUN([OH_CHECK_OPENIPMI],
}'`
fi
- if test "$OPENIPMI_VERSION" == "OK"; then
+ if test "$OPENIPMI_VERSION" = "OK"; then
have_openipmi=yes
AC_MSG_RESULT(yes)
else
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. The actual enums don't seem to
be used in the source; I'm not yet familiar enough with OpenHPI to know
how they're supposed to be used.
3) PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP not defined.
Used in plugins/ipmidirect/thread.cpp . With the _NP suffix implying
nonportable it's not surprising that this doesn't work.
4) Unknown assembly pseudo-op .weakref
Used in plugins/ipmidirect/ipmi_mc_vendor_sun.s . It looks like the
stock binutils used by FreeBSD is just too old, so the port will just
have to use an explicit newer version.
Right now this is just an initial investigation - if I continue on and
make progress I'll report back.
Regards,
Ed
------------------------------------------------------------------------------
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
