All of lore.kernel.org
 help / color / mirror / Atom feed
From: Otavio Salvador <otavio@ossystems.com.br>
To: Phil Blundell <philb@gnu.org>
Cc: OE-core <openembedded-core@lists.openembedded.org>
Subject: Re: [oe] [RFC] OpenGL packaging/staging policy
Date: Mon, 22 Oct 2012 15:38:03 -0200	[thread overview]
Message-ID: <CAP9ODKojRUw1perOMbT6VCzFsU22SiCMbifboCo7fb58oyzOMw@mail.gmail.com> (raw)
In-Reply-To: <1350927160.3259.343.camel@phil-desktop>

On Mon, Oct 22, 2012 at 3:32 PM, Phil Blundell <philb@gnu.org> wrote:
> On Mon, 2012-10-22 at 17:35 +0100, Burton, Ross wrote:
>> Rule 3. Only Mesa stages, nothing else
>>
>> Whilst there are multiple GL implementations that offer various
>> subsets of GL, they are all effectively interchangeable.  It's not a
>> massive concern what exact GL is present when building because they've
>> all got the same API.
>
> This is an attractive idea but I'm not sure that the underlying
> assumption is entirely correct.
>
> Different GL libraries will have different vendor extensions and Mesa's
> headers won't necessarily know about them.  If the vendor ships the
> extension bits in a custom header (rather than jamming them into a
> modified glext.h) then this could be worked around by staging the
> headers separately, but you're still left with the problem that Mesa's
> libGL.so might now be missing symbols that are required during
> linking.
>
> Also, even if the APIs were the same, I am slightly nervous about
> relying on all vendor GLs having an identical ABI to Mesa.  I can't
> immediately think of any reason why they shouldn't but, equally, vendors
> have been known to do peculiar things in the past and I wouldn't be
> totally shocked to find that there is some binary libGL out there which
> manages to be ABI-incompatible with Mesa in some or other creative
> fashion.

In this case every package depending on GL packages will be
PACKAGE_ARCH specific; this would be nice if we can share it amoung
boards at least.

-- 
Otavio Salvador                             O.S. Systems
E-mail: otavio@ossystems.com.br  http://www.ossystems.com.br
Mobile: +55 53 9981-7854              http://projetos.ossystems.com.br



  reply	other threads:[~2012-10-22 17:51 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-22 16:35 [RFC] OpenGL packaging/staging policy Burton, Ross
2012-10-22 17:19 ` Tomas Frydrych
2012-10-22 19:27   ` Burton, Ross
2012-10-22 20:25     ` Tomas Frydrych
2012-10-23  2:06   ` Daniel Stone
2012-10-23  8:37     ` Tomas Frydrych
2012-10-23  9:18       ` Daniel Stone
2012-10-23  9:49         ` Tomas Frydrych
2012-10-29 17:26           ` Burton, Ross
2012-10-29 17:26             ` [OE-core] " Burton, Ross
2012-10-29 18:27             ` Tomas Frydrych
2012-11-20 16:52             ` Burton, Ross
2012-11-20 16:52               ` [OE-core] " Burton, Ross
2012-10-22 17:32 ` [oe] " Phil Blundell
2012-10-22 17:38   ` Otavio Salvador [this message]
2012-10-22 19:26   ` Burton, Ross
2012-10-22 17:33 ` Otavio Salvador
2012-10-22 17:33   ` [OE-core] " Otavio Salvador
2012-10-22 19:25   ` Phil Blundell
2012-10-22 19:25     ` [OE-core] " Phil Blundell
2012-10-22 17:37 ` Mark Hatle
2012-10-22 19:29   ` Burton, Ross

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=CAP9ODKojRUw1perOMbT6VCzFsU22SiCMbifboCo7fb58oyzOMw@mail.gmail.com \
    --to=otavio@ossystems.com.br \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=philb@gnu.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.