Re: pandaboard/omap4 support

[Denys Dmytriyenko <denys@ti.com>]

On Wed, Feb 12, 2014 at 08:38:04AM -0800, Khem Raj wrote:
> 
> On Feb 12, 2014, at 8:28 AM, Denys Dmytriyenko <denys@ti.com> wrote:
> 
> > On Wed, Feb 12, 2014 at 03:15:38PM +0100, Richard Röjfors wrote:
> >> On Wed, Feb 12, 2014 at 3:07 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >> 
> >>> 
> >>> On Feb 12, 2014, at 6:03 AM, Richard Röjfors <richard.rojfors@gmail.com>
> >>> wrote:
> >>> 
> >>> On Wed, Feb 12, 2014 at 2:52 PM, Khem Raj <raj.khem@gmail.com> wrote:
> >>> 
> >>>> 
> >>>> what incompatibilities do you see between 4.7 and 4.8 ?
> >>>> 
> >>> 
> >>> I saw this in the gcc 4.8 changelog:
> >>> "On ARM, a bug has been fixed in GCC's implementation of the AAPCS rules
> >>> for the layout of vectors that could lead to wrong code being generated.
> >>> Vectors larger than 8 bytes in size are now by default aligned to an 8-byte
> >>> boundary. This is an ABI change: code that makes explicit use of vector
> >>> types may be incompatible with binary objects built with older versions of
> >>> GCC. Auto-vectorized code is not affected by this change.”
> >>> 
> >>> 
> >>> OK. are you seeing this use case here ?
> >>> 
> >> 
> >> Nope I've not hit it nor gone through the calls between the blobs and the
> >> surrounding code.
> >> 
> >> I just think it makes sense to compile the blobs with a compiler similar to
> >> the one provided by oe-core, to avoid the risk...
> > 
> > The biggest problem is not 4.7 vs. 4.8, but rather incompatibilities in ABIs 
> > and call conventions. E.g. we have switched to hardfp for our products and 
> > some of our components distributed in binary form are only available in hardfp 
> > format. And oe-core doesn't use hardfp by default yet…
> > 
> 
> yes thats a genuine concern, so when you publish prebuilt components then demand
> the required ABI compatibilities, but there isn’t much else one can do.

Indeed, I do this for now:

http://git.yoctoproject.org/cgit/cgit.cgi/meta-ti/tree/recipes-graphics/libgles/libgles-omap3_5.01.00.01.bb#n25

I was hoping this would be a temporary limitation and there might be a softfp 
binary released too...

-- 
Denys