Where is libGLcore.so ?
dbn.lists at gmail.com
Mon May 12 08:22:30 PDT 2008
On Mon, May 12, 2008 at 7:56 AM, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Sun, May 11, 2008 at 1:22 PM, Dan Nicholson <dbn.lists at gmail.com> wrote:
> > On Sat, May 10, 2008 at 7:03 PM, <pcpa at mandriva.com.br> wrote:
> > > Quoting Ritesh Sood <riteshsood at gmail.com>:
> > >
> > >> So now my question is, where is libGLcore.so, and what am i missing ?
> > >
> > > You need to run "make glcore glcore-install" in the mesa build.
> > >
> > > But I believe something must be done about it, as now there is a
> > > cyclic dependency of X Server and mesa for the glcore targets.
> > I think that's just how it's going to be because glcore depends on the
> > xserver and internal parts of mesa. The alternative is to go back to
> > pulling in nearly all of the mesa source into the build. This broke
> > often, and now all that's needed is a few files to build GLX.
> > You're best to just treat GLcore like it's a separate package, just
> > that it happens to use the same mesa sources. I have a patch
> > pending that should make the process like this:
> > 1. Build mesa DRI using --with-driver=dri
> This step shouldn't depend on the X server.
> > 2. Build xserver
> > 3. Build mesa GLcore using --with-driver=glcore
> I haven't done a build from scratch recently, but with the glcore
> changes, we should be able to just say
> 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
> 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
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
More information about the xorg