"Mike A. Harris" wrote:
>
> On Sat, 19 May 2001, David Dawes wrote:
>
> >>In our specfile, right after everything is built, and installed
> >>into a builtroot dummy area via RPM, we delete Mesa with the
> >>following code in our specfile:
> >>
> >>
> >>{
> >> rm -f $RPM_BUILD_ROOT/usr/include/GL
> >> find $RPM_BUILD_ROOT/usr/lib -type f |grep -vi "glide"|xargs rm -f
> >> rm -rf $RPM_BUILD_ROOT/usr/X11R6/include/GL
> >> rm -f $RPM_BUILD_ROOT/usr/X11R6/lib/libGL* \
> >> $RPM_BUILD_ROOT/usr/X11R6/lib/libOSM*
> >>}
> >>
> >>Instead of this hack, is there a clean way to disable the
> >>included Mesa from getting built in the first place? Nothing
> >>seems apparent from the config dir:
> >
> >Which part exactly do you want to disable? I'm sure someone can
> >correct me if I'm wrong, but my understanding is that Mesa is built
> >in to the DRI drivers, and that our libGL contains support for
> >loading the appropriate drivers for direct rendering, or using GLX
> >to send indirect rendering request to the X server (which has Mesa
> >built in to handle them). I think Mesa is only built in directly
> >to libGL if GlxBuiltInMesa is set to YES (which it isn't for our
> >builds).
>
> I could be reading things wrong then.
>
> >>We use a separate Mesa lib, and _MUST_ use the separate Mesa lib until
> >>3.3.6 is no longer needed in Red Hat Linux. I'd just like to make
> >>this part of the build a bit cleaner, as it wastes a lot of time
> >>building something that gets deleted, and I'm having failures in the
> >>Mesa asm code getting built right now, which sucks because it will
> >>be deleted anyway.
> >
> >I don't know why you're having those build problems.
> >
> >I guess what you really need is a way of making our libGL load
> >a Mesa module compatible with 3.3.6?
>
> Our separate mesa package is created from a checkout of Mesa
> source from the Mesa3d project on sourceforge. After that, and
> yes, this is a hacky mess... ;o) we do the following:
>
> rpm -bp XFree86.spec (this executes an unpzcking of the XFree86
> source code, applies all patches from the spec file then stops
> without initiating a build.
>
> Then we tar up portions of this installed X source tree:
>
> Source: ftp://ftp.mesa3d.org/mesa/beta/Mesa-%{version}.tar.bz2
> Source2: XFree86-4.0.3-13-GLonly.tar.bz2
> # Create Source2 from XFree86 using
> # tar Icf XFree86-version-release-GLonly.tar.bz2 \
> # xc/include/extensions/extutil.h \
> # xc/include/GL xc/lib/GL \
> # xc/programs/Xserver/hw/xfree86/os-support/xf86drm* \
> # xc/programs/Xserver/GL/dri/*.h
>
> and in the Mesa unpack/patch/build process:
>
> %prep
> %setup -q
> find . -type d -name CVS |xargs rm -rf
> mkdir -p src/DRI/GL
> bzcat %{SOURCE2} |tar xf -
> ln -f `find xc -type f` src/DRI
> mv -f src/DRI/glxmd.h src/DRI/GL/glxmd.h
> %patch1 -p1 -b .xf86dri
> %patch4 -p1 -b .libtool
> %patch5 -p1 -b .glibc22
> %patch6 -p1 -b .context
> %patch7 -p1 -b .nopthread
>
> I would very much like to not have to do this, and I believe that
> instead of integrating parts of XFree86 into Mesa, it might be
> possible to integrate parts of Mesa that are missing - into
> XFree86 instead, and I would very much prefer it if it were that
> way. Even better if XFree86 came that way, so that we could
> build XFree86 from CVS and have Mesa work on 3.3.6 as well.
>
> I have no idea where to start though to do that myself. Any help
> on doing this would be greatly appreciated.
I think we've been over this before but let's see I've got the whole
picture.
The core problem is that you need a different libGL.so depending on
whether XFree86 3.3.6 or 4.x is being run, right?
Both 3.3.6 and 4.x might be installed at the same time as well, right?
If you're running 4.x then you'll always get the GLX server extension
regardless of the hardware installed. And hence, OpenGL capability.
With 3.3.6 there isn't a GLX server extension so OpenGL capability is
provided by "stand-alone" Mesa, which is version of libGL.so which
effectively converts GL calls into Xlib protocol which renders on any
X display.
Another scenario is someone using the XFree86 4.x libGL.so who wants
to remote-display to an XFree86 3.3.6 server. libGL.so will look for
the GLX extension on the 3.3.6 server, not find it, and die. In this
case you'd like to have libGL.so fallback to "stand-alone" mode and
generate Xlib protocol.
Previously, you made a hybrid libGL.so that was both GLX/DRI-aware
and could also fallback to stand-alone/Xlib mode. Is that no longer
working? I seem to recall hearing of some problems with it.
I remember getting a patch for this hybrid libGL long ago but never
incorporated it because I was too busy and not 100% sure it was the
right thing to do. Maybe I should revisit this if it'll help.
-Brian
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
