public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: "Anton Pak" <anton.pak@pigeonpoint.com>
To: openhpi-devel@lists.sourceforge.net
Cc: LTP list <ltp-list@lists.sourceforge.net>
Subject: Re: [LTP] [Openhpi-devel] [PATCH] Cross-compile configure bug
Date: Tue, 25 Aug 2009 19:19:25 +0400	[thread overview]
Message-ID: <op.uy74unolo8angs@localhost> (raw)
In-Reply-To: <1251213123.7108.8.camel@orthanc>

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

On Tue, 25 Aug 2009 19:12:03 +0400, Shuah Khan <shuah.khan@hp.com> wrote:

> On Tue, 2009-08-25 at 05:42 +0000, anton.pak@pigeonpoint.com 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 <yanegomi@gmail.com>
>> >>
>> >> ---
>> >>  
>> /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
>> >>
>> >>  
>> ------------------------------------------------------------------------------
>> >> 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
>> >> Openhpi-devel@lists.sourceforge.net
>> >> https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >
>> >
>> >  
>> ------------------------------------------------------------------------------
>> > 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
>> > Openhpi-devel@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/openhpi-devel
>> >
>>
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>> Openhpi-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/openhpi-devel



------------------------------------------------------------------------------
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
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list

  reply	other threads:[~2009-08-25 15:19 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-19 23:11 [LTP] [PATCH] Cross-compile configure bug Garrett Cooper
2009-08-23  7:28 ` Subrata Modak
2009-08-25  1:15 ` [LTP] [Openhpi-devel] " Ric White
2009-08-25  5:42   ` anton.pak
2009-08-25 15:12     ` Shuah Khan
2009-08-25 15:19       ` Anton Pak [this message]
2009-08-25 17:42         ` Shuah Khan
2009-08-26  0:16           ` Garrett Cooper
2009-08-27  0:51             ` Ric White

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=op.uy74unolo8angs@localhost \
    --to=anton.pak@pigeonpoint.com \
    --cc=ltp-list@lists.sourceforge.net \
    --cc=openhpi-devel@lists.sourceforge.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox