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.
Thanks,
TTYL
----------------------------------------------------------------------
Mike A. Harris Shipping/mailing address:
OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie,
Red Hat Inc. Ontario, Canada, P6C 5B3
http://www.redhat.com Phone: (705)949-2136
----------------------------------------------------------------------
Latest XFree86 test RPMS: ftp://people.redhat.com/mharris/testing
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
