[Mesa-dev] [PATCH Resend] mesa: Optionally build a dricore support library.
Keith Whitwell
keith.whitwell at gmail.com
Fri Dec 24 05:54:33 PST 2010
On Fri, Dec 24, 2010 at 4:12 AM, Christopher James Halse Rogers
<christopher.halse.rogers at canonical.com> wrote:
> On Tue, 2010-12-21 at 08:58 +0000, Keith Whitwell wrote:
>> This promotes a private interface to a public one, right? If so that
>> isn't really doing us any favours as next people will complain when that
>> newly public interface varies between releases.
>
> Not really; the new libraries are private (contained within
> $DRI_INSTALL_DIR, so /usr/lib/dri by default) and unversioned. This is
> not significantly different to, say, the shared objects in /usr/lib/egl
> which have come and gone without complaint.
>
> This patch does *not* expose any additional interfaces in the public
> libGL, GLES, etc libraries. Where objects need to be built with default
> visibility, they're built twice; once with -fvisibility=hidden for the
> code destined for the public libraries, once without for the shared,
> private libraries.
>
>>
>> If you want to save disk space by sharing components, what about an
>> alternate approach -- investigate methods for building all the DRI
>> drivers into a single binary? That would keep the internal interface
>> private & possibly share more space than this approach.
>>
> It would indeed save a bit more space, and also apply more easily to the
> gallium drivers. It'd require a much larger patch though - we'd need to
> change the libGL←→dri driver interface and patch X to keep up, right?
>
> If that's the direction you'd prefer to go, I could look at doing that.
> I think it'd be substantially more invasive, though, and more difficult
> to make optional.
I don't think my concerns are sufficient to hold this up -- if others
aren't concerned then guess I'm ok with this as an optional mechanism
for environments where version skew is unlikely, such as live cds.
Keith
More information about the mesa-dev
mailing list