On Tue, Aug 25, 2009 at 10:42 AM, Shuah Khan<[email protected]> wrote:
> On Tue, 2009-08-25 at 15:19 +0000, Anton Pak wrote:
>> I tried many times OpenHPI on x86_64.
>> It worked fine in the configurations x86 client - x86_64 daemon and x86_64
>> client - x86 daemon.
>> However, the functioning on non-x86 64-bit platform or on Itanium is still
>> an open question for me.
>>
>> Anton Pak
>
> Instead of changing the error to a warning, itcould be controlled via a
> config option, so this error could be ignored on certain architectures
> using this config tune.
>
> -- Shuah
>>
>> On Tue, 25 Aug 2009 19:12:03 +0400, Shuah Khan <[email protected]> wrote:
>>
>> > On Tue, 2009-08-25 at 05:42 +0000, [email protected] wrote:
>> >> Hello!
>> >>
>> >> We have the following lines in include/SaHpi.h:
>> >>
>> >> typedef unsigned char SaHpiUint8T;
>> >> typedef unsigned short SaHpiUint16T;
>> >> typedef unsigned int SaHpiUint32T;
>> >> typedef signed char SaHpiInt8T;
>> >> typedef signed short SaHpiInt16T;
>> >> typedef signed int SaHpiInt32T;
>> >>
>> >> Also I suspect there can be marshalling issues, i.e. when
>> >> daemon on platform with sizeof(int) == 4 but library is not and vice
>> >> versa.
>> >>
>> >> Anton Pak
>> >
>> > The proposed fix might help compile OpenHpi on a 64-bit platform,
>> > however I agree with the concerns from others that we will see run-time
>> > issues. Running 32-bit binary and libraries on a 64-bit platform might
>> > be an option.
>> >
>> > -- Shuah
>> >
>> >
>> >>
>> >>
>> >> > Hi Garrett,
>> >> >
>> >> > I was wondering about your addition of the cross_compiling test. If
>> >> > there is OpenHPI code that may behave badly on a system where an int
>> >> > isn't 4 bytes, I'm thinking that a warning should be issued even for a
>> >> > cross compile to such an architecture as well. Like:
>> >> >
>> >> > if test "x$OH_SIZEOF_INT" != "x4"; then
>> >> > AC_MSG_WARN([
>> >> > *** int is not 4 bytes, it is $OH_SIZEOF_INT bytes on this platform
>> >> > *** undefined behavior may result from this.
>> >> > ])
>> >> > fi
>> >> >
>> >> > Will having a warning instead of an error cause problems for LTP when
>> >> > cross compiling?
>> >> >
>> >> > Does anyone else in the OpenHPI community oppose changing this error
>> >> to
>> >> > a warning?
>> >> >
>> >> > Best Regards,
>> >> > Ric White
>> >> >
>> >> >
>> >> > On Wed, 2009-08-19 at 23:11 +0000, Garrett Cooper wrote:
>> >> >> Hi,
>> >> >> Found this bug while trying to cross-compile with the
>> >> >> openhpi-test-suite in LTP, and made the ERROR into WARN. Please fix
>> >> >> this item as per the attached patch.
>> >> >> Thanks,
>> >> >> -Garrett
>> >> >>
>> >> >> PS Please CC my address in all correspondence w.r.t. this email
>> >> thread.
>> >> >>
>> >> >> Summary:
>> >> >>
>> >> >> 1. int != 4 shouldn't be checked for while cross-compiling.
>> >> >> 2. Warn instead of erroring out, because we have a _lot_ of 64-bit
>> >> >> platforms that we test on which will be negatively impacted by this
>> >> >> check.
>> >> >>
>> >> >> Signed-off-by: Garrett Cooper <[email protected]>
>> >> >>
>> >> >> ---
>> >> >>
>> >> /nfs.mac/ltp-upgrade/contrib/ltp/src/testcases/open_hpi_testsuite//configure.ac.orig
>> >> 2009-08-19
>> >> >> 16:04:08.000000000 -0700
>> >> >> +++
>> >> >>
>> >> /nfs.mac/ltp-upgrade/contrib/ltp/src/testcases/open_hpi_testsuite//configure.ac
>> >> 2009-08-19
>> >> >> 16:10:47.000000000 -0700
>> >> >> @@ -44,14 +44,13 @@
>> >> >> AC_PROG_LN_S
>> >> >> AC_PROG_MAKE_SET
>> >> >>
>> >> >> -dnl die on int != 32bits. This is too instrumental to our code
>> >> right
>> >> >> now.
>> >> >> +dnl Warn when int != 32bits. This is too instrumental to our code
>> >> >> right now.
>> >> >> dnl AC_MSG_CHECKING(int is 4 bytes)
>> >> >> OH_SET_SIZES
>> >> >> -if test "x$OH_SIZEOF_INT" != "x4"; then
>> >> >> - AC_MSG_ERROR([
>> >> >> +if test x$cross_compiling != xyes && test "x$OH_SIZEOF_INT" != "x4";
>> >> >> then
>> >> >> + AC_MSG_WARN([
>> >> >> *** int is not 4 bytes, it is $OH_SIZEOF_INT bytes on this platform
>> >> >> -*** undefined behavior will result
>> >> >> -*** please contact the openhpi development team to fix this
>> >> >> +*** undefined behavior may result from this.
>> >> >> ])
>> >> >> fi
Shuah,
Whichever way you find necessary is fine as long as it doesn't
break builds and there are sufficient warnings at both buildtime and
at runtime that say `Hey -- this code might not work because of
integer sizing issues!' so you guys can cover yourself from FAQ-like
questions as much as possible :).
Thanks,
-Garrett
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Openhpi-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/openhpi-devel
