Where is libGLcore.so ?

[Kristian Høgsberg]

On Mon, May 12, 2008 at 2:34 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> On Mon, May 12, 2008 at 11:06 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
>  > On Mon, May 12, 2008 at 11:22 AM, Dan Nicholson <dbn.lists at gmail.com> wrote:
>  >  >
>
> >  >  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.
>
>  I'm not really worried about that part - I'm confident that the few
>  people that touch the generators can remember to sync the created
>  files into the xserver. What I'm more concerned about is not always
>  keeping the xserver and mesa in lockstep. In other words, what happens
>  if I update to a new mesa release and its glapi is out-of-sync with
>  libglx? Is that an issue?

You can't keep them in lock step anyway - do a mesa build and install
it, then udpate mesa to a incompatible version and do an xserver build
and they're out of sync even with our current symlink technique.  The
underlying problem is that the glapi interface is part of the DRI
drivers and if it ever breaks, the DRI driver interface breaks.  This
won't change whether we symlink or not.  I don't think it's a big
deal, but breaking the compile time dependency on mesa source is
major, in my opinion.

cheers,
Kristian