On Thu, May 10, 2001 at 09:59:17AM -0400, Allen Barnett wrote:
> Hi,
>
> I'm not sure if this package is intended for developers and on
> non-Debian systems, but I fearlessly tried it out on my RedHat 7.1
> installation anyway. If I missed the point, please ignore the following.
>
> I tested the i386/tdfx combination on a 3500TV. Except for one problem,
> pure OpenGL apps run OK. I ran into a problem with the presence of
> /usr/lib/libGL.so from the RH 7.1 Mesa RPM installation. Unless you put
> LD_LIBRARY_PATH=/usr/X11R6/lib in the environment, all installed RH 7.1
> OpenGL applications segmentation fault immediately in
> driMesaBindContext(). Perhaps the installation scripts should move the
> libraries in /usr/lib out of the way, too? Or at least ask the user
> about it? Otherwise, installed Mesa and Mesa-devel RPMs should probably
> be removed. In which case, it would be nice if the package included the
> Mesa header files, too.
>
There was a 'force' option to do this, but it never worked. So I've just
made some changes so it does it automagically now.
As for the header files. We're assuming your running a full install of
XFree86 4.0.3 with these packages (I know it doesn't say anywhere though),
and that includes all the necessary pieces outside of what the binary
drivers are trying to do. Which is just upgrade to the current latest drivers.
If you'd like to work on an RPM package format that can remove/upgrade/check
current RedHat installs that would be great!
> Also, it appears that libGLU is the SGI SI? This is great! I tried
> relinking my own C++ application against libGL and libGLU in
> /usr/X11R6/lib. This yielded a couple of problems. First, either the
> installation script or ldconfig did not create a
> '/usr/X11R6/lib/libGLU.so' symlink to the real libGLU.so.1.3, therefore
> the linker picked up the one in /usr/lib (which is the Mesa 3.4 GLU in
> RH 7.1). [Here, I must admit ignorance. Perhaps someone would be willing
> to explain to me (off-line, maybe) exactly how ld, ld.so and ldconfig
> are supposed to interact with the version numbers on shared objects.
> What does ld look for that's different from what ld.so looks for, for
> example?]
>
The dynamic linker is a pain. We've seen some that work from top->down in
the ld.so.conf file and others work bottom->up. So, depending on the
ordering in this file you could end up with the wrong libraries linked.
The changes I've made to the install script today should enforce the
DRI libraries to be linked now. The new packages from 20010511 will be
made into a v0.6 release tomorrow.
> I added the symlink by hand and it linked OK. However, my program
> segmentation faults the first time it tries to do a dynamic_cast<>(). I
> suspect this results from using the RH 7.1 version of GCC 2.96. If I
> compile the SI GLU (which is a C++ library, itself) from the current
> Mesa CVS, my code works without problems. (I installed the RH 6.2 EGCS
> compatibility packages, too, and it got further, but my program uses Qt
> which is only available compiled with GCC 2.96, so it still aborts.)
>
> Lastly, it would be nice if the OpenGL man pages where included, too
> (see ftp://ftp.sgi.com/opengl/doc).
>
The current CVS of XFree86 has all the OpenGL man pages and pre-formatted
GLU pages. When the next merge from XFree86 happens - we'll pick them
changes up.
Alan.
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/dri-devel
