Re: [Dri-devel] [ANNOUNCE] v0.5 DRI release

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

On Thu, May 10, 2001 at 09:59:17AM -0400, Allen Barnett wrote:
> 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.

We have a bit of a problem with install scripts. Making them work for
all the distributions is tough. We're trying to get there, but we need
people to work on them. In reality the "better" way to install is to get
a whole native package from your distribution. Our install scripts try
to "update" that to the latest versions of our code.

So if anyone wants to step up and help with the script issues on one or
more distributions, please do!

> 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.

We've sort of assumed that this is more for users than developers which
is why headers weren't included, but that's a reasonable suggestion. I
thought we were moving the old libraries out of the way, but either we
missed something or we're not doing that.

> 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?]

Yes, this is the SGI GLU. 

> 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.)

That's an ugly problem. C++ compiled under RH 6.2 is different that C++
compiled under RH 7.0 which is different than C++ compiled under RH
7.1. We're sort of stuck with this until GCC 3.0 is released with a new
standard. The install script has the capability to handle architecture
dependent packages, but we haven't gotten that far.

> Lastly, it would be nice if the OpenGL man pages where included, too
> (see ftp://ftp.sgi.com/opengl/doc).

I would love to, but I haven't been able to get a straight answer out of
anyone from SGI on the legal status of those pages. We can't take them
until we know they aren't restricted by some copyright. I should try
pinging them again and maybe we can get that into 4.1.

						- |Daryll