Where is libGLcore.so ?

Kristian Høgsberg krh at bitplanet.net
Mon May 12 11:06:01 PDT 2008


On Mon, May 12, 2008 at 11:22 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Mon, May 12, 2008 at 7:56 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
...
>  >   1. Build X server
>  >   2. Build mesa with GLcore and dri drivers
>
>  But the X server requires dri_interface.h and dri_sarea.h for AIGLX
>  and DRI2, remember? So, you have to install mesa first, unless you
>  want to put those headers somewhere else or keep a copy in the X
>  server.

Oh oops... I feel like a goldfish now :)

>  >  Also, I was never a big fan of symlinking the generated dispatch files
>  >  from mesa, I'd rather just generate them from mesa straight into the X
>  >  server tree and the commit that.  It's rare enough that we do this
>  >  that and only developers need to do this.  Considering that this will
>  >  break the compile time dependency on mesa sources, I think that's a
>  >  worthwhile tradeoff, even if we'll have to also duplicate
>  >  glcontextmodes.[ch].
>
>  The other drawback being that things can get out of sync. You
>  certainly know more about how that API holds up, but it seems like it
>  would break if, say, one of the API symbols in indirect_size.h existed
>  in mesa, but not in xserver. The other thing I was thinking would to
>  make a small library from the generated files and link that into libGL
>  and libglx.

Georges patches get rid of glcontextmodes.[ch] (I think he didn't
actually drop those in his patches, but we should).  Aside from those,
all the shared files are generated from one canonical description, so
I don't feel it's a big problem to scatter the generataed files into
different repositories.  It makes it a little bit trickier to update
the GL definitions, but that's already pretty tricky as it is.
Besides, we can make the scripts error out if they can't find an
xserver checkout to generate into, and print a reminder about also
committing the xserver files.

Kristian


More information about the xorg mailing list