Re: [Dri-devel] compiling DRI problems/adventure

[Daryll S. <da...@pr...>]

On Mon, Dec 13, 1999 at 12:27:44PM -0600, Brynn Rogers wrote:
> I am looking at the glXMakeCurrent bug which may be the reason performer
> fails to work.
> 
> I did get the xserver to compile and install, but there are couple
> questions that came up when I was doing so.
> 
> 1.  make world failed initially, and looking at this list I found that
> the answer was to install glide 
> first.  Why is glide not in the Xserver cvs tree?

Because Glide is under a different license. We haven't worked out what's
needed for integrating the two yet. It also seems sort of wrong to just
throw everything into X. Mesa has to be there, because we modify it as
we build it into X, but it seems like Glide is distinct enough we could
avoid that.

> 2.  I got the
> http://linux.3dfx.com/open_source/download/srpm/Glide_V3-DRI-3.10-4.src.rpm 
> and did a rpm -i Glide...,
> followed by rpm -bi /usr/src/redhat/SPECS/Glide_V3...    That seems to
> work fine but make world still failed.  I figured out
> that the build from rpm put the needed files in /tmp/something/include
> and /tmp/something/lib.  so I copied those to
> the /usr/include and /usr/lib and then make world worked!    
> 2a.  is this the right glide to install?
> 2b.  why did it build to the /tmp directory and not install it right?

Yes, you need the SDK and the DRI libraries. I haven't looked at the
Glide3x packages yet. Building the RPM builds in a BuildRoot which is
tmp. That's standard for RPMS these days so that you don't corrupt your
development system while building the package. That's a reasonable way
to install glide. There should be a glide3x SDK RPM which does that for you.

> 3.  I can't get the oglinfo.c that an SGI person hacked into a simple
> test case for the problem (called stuff.c) that came from
> the mesa sample directory to compile.   I suspect I am using the wrong
> mesa.   should I be using the mesa code in the xc/xc tree?

Now to the real meat. We've got two different fixes to the "performer"
problem one of which will get checked in today. I did a quick hack (2
lines) that worked around the problem. Kevin rewrote a major chunk of
code to do it "right." The problem is his solution appears to have
uncovered another bug elsewhere in the X server. So we will check in a
working solution today. I just don't know if it'll be the hack or the
correct fix. Currently Kevin's big fix is in glxext.c and it doesn't
work, so hang in there a bit.

> 4.  After getting make world to work, I tried make install.   This
> didn't work for me at first because my xc/xc tree was on an NFS mounted
> drive, and due to some strange permission thing root on my openGL/fun
> box was not able to unlink some symlinks.   After cp -a /nfs/xc
> /anotherext2part  the make install went fine.   Shouldn't a build and
> install from an NFS partition work?  

That's normal NFS. NFS does something called "root squash." It removes
privledges when root accesses the file system from a remote
directory. So, no, this shouldn't work unless you allow root to operate
correctly on a remote NFS. On Linux, you have to set /etc/exports
something like this: 
	  /mnt/devel foo(rw, no_root_squash)

> 5. currently the openGL/fun box is a celeron 333.  I am contemplating
> upping it to a dual celeron 366 (oc'ed to 550).  Is make world set up
> for parallel makes? (define some MAKEOPT = -j4 or something fun)  Would
> that speed up the compile?

The correct "full world" build command is:
    make World WORLDOPTS="-j3 MAKE='make -j3'"
That'll cut compiles by about 30%.

The problem is that it doesn't build reliably that way. There must be
some dependency that make can't determine, because it fails and then you
restart it and it finishes. I don't know why. That really negates the
speed up of the multiprocess compile, because you have to watch it and
start it again.

						- |Daryll