plib-users

[Plib-users] Error: can not find working glut

[<KSt...@ne...>]

Hi all you guys! I am new to this list. You know, I am facing the same problem with our friend Andrew here:

> Andrew Karpenko wrote:
> > checking for glutGetModifiers in -lglut... no
> > configure: error: could not find working GLUT library

I understand the source of my problem

> ...pretty much what it says - you don't have GLUT installed properly.
> You should have /usr/include/GL/glut.h and /usr/lib/libglut.a or
> libglut.so

but I don't know what to do to get things right. Specifically, I don't have a /usr/include/GL/glut.h header file. I installed glut-3.7-8 via
rpm at RH8 ,so, libglut.so.3.7 appeared in /usr/lib (but no .h file at /usr/include/GL). Any ideas how to work around this problem? Thanks in advance.

Cheers,
Kyriakos


__________________________________________________________________
The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp 

Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/

Re: [Plib-users] Error: can not find working glut

[Bernie B. <bb...@bi...>]

On Sun, 26 Jan 2003 14:19:32 -0500
KSt...@ne... wrote:

> 
> Hi all you guys! I am new to this list. You know, I am facing the same
> problem with our friend Andrew here:
> 
> > Andrew Karpenko wrote:
> > > checking for glutGetModifiers in -lglut... no
> > > configure: error: could not find working GLUT library
> 
> I understand the source of my problem
> 
> > ...pretty much what it says - you don't have GLUT installed properly.
> > You should have /usr/include/GL/glut.h and /usr/lib/libglut.a or
> > libglut.so
> 
> but I don't know what to do to get things right. Specifically, I don't have
> a /usr/include/GL/glut.h header file. I installed glut-3.7-8 via rpm at RH8
> ,so, libglut.so.3.7 appeared in /usr/lib (but no .h file at
> /usr/include/GL). Any ideas how to work around this problem? Thanks in
> advance.

You also need to install the -devel rpm.  I don't use RedHat but on my
Mandrake 9.0 machine I have libMesaglut3-4.0.3-6mdk as well as
libMesaglut3-devel-4.0.3-6mdk.

Bernie

Re: [Plib-users] Error: can not find working glut

[Steve B. <sjb...@ai...>]

KSt...@ne... wrote:

> but I don't know what to do to get things right. Specifically, I don't have a /usr/include/GL/glut.h header file. I installed glut-3.7-8 via
> rpm at RH8 ,so, libglut.so.3.7 appeared in /usr/lib (but no .h file at /usr/include/GL). Any ideas how to work around this problem? Thanks in advance.

I suspect an annoying (but growing) trend with distro makers that they have TWO versions of every RPM
that relates to libraries - one is the "Development Version" - which comes with headers and binaries,
the other contains *just* the binaries.

I've seen this with the latest version of SuSE and it's *INCREDIBLY* annoying.

The header files take up very little space - and if they install the library without the headers
then it can only be used by binary-only applications.  When you try to install a source-code based
project, it *looks* like the library is installed when you ask RPM about it - but in fact it's
only halfway installed.

We never used to get this kind of complaint - but now I see them all the time.

So, look for a RedHat RPM with "Development" or "Developer" somewhere in it's title - and you'll
have what you need.

Failing that, you can download GLUT and you can either install it yourself - or (if you prefer not
to screw up the existing RPM install) just copy the header files into /usr/include/GL/

GLUT is to be found on www.opengl.org and on www.mesa3d.org - as a part of the Mesa install.

You need 'glut.h'...that's all I think.

---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...>    WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net    http://tuxaqfh.sf.net
            http://tuxkart.sf.net http://prettypoly.sf.net

Re: [Plib-users] Error: can not find working glut

[Curtis L. O. <cu...@fl...>]

Steve Baker writes:
> I suspect an annoying (but growing) trend with distro makers that
> they have TWO versions of every RPM that relates to libraries - one
> is the "Development Version" - which comes with headers and
> binaries, the other contains *just* the binaries.
> 
> I've seen this with the latest version of SuSE and it's *INCREDIBLY*
> annoying.

Debian has done this for quite some time.

The regular part comes with just the .so's, the ; the -dev portion includes
the headers and the .a's in case any developers would want to
statically link.

> The header files take up very little space - and if they install the
> library without the headers then it can only be used by binary-only
> applications.  When you try to install a source-code based project,
> it *looks* like the library is installed when you ask RPM about it -
> but in fact it's only halfway installed.

Without touching on what *should* be done, I believe the intention is
exactly what you allude to ... install the minimum possible portion of
the library to allow binaries to run.  Remember packaging for most
people is all about pre-compiled binaries.

There are some benefits to this approach.  It minimizes download times
and hard drive consumption (don't forget that the -dev versions of the
lib package also include the .a's.)  It gives *most* people exactly
what they want.

It's been this way on Debian ever since I can remember so I'm used to
it and don't think twice about apt-get'ing the -dev portion.

But, to be fair, there is a downside to this approach (which touches
on some of the down sides to package management in general.)

I'll make you a deal: As soon as you come up with a scheme that does
exactly what *everyone* wants 100% of the time, I'll invest my life
savings in your company, or vote for you, or do what ever is
appropriate for your particular scheme. :-)

Curt.
-- 
Curtis Olson   IVLab / HumanFIRST Program       FlightGear Project
Twin Cities    cu...@me...                  cu...@fl...
Minnesota      http://www.menet.umn.edu/~curt   http://www.flightgear.org

Re: [Plib-users] Error: can not find working glut

[Tony P. <ap...@ea...>]

On Sun, 2003-01-26 at 13:35, Curtis L. Olson wrote:
> Steve Baker writes:
> > I suspect an annoying (but growing) trend with distro makers that
> > they have TWO versions of every RPM that relates to libraries - one
> > is the "Development Version" - which comes with headers and
> > binaries, the other contains *just* the binaries.
> > 
> > I've seen this with the latest version of SuSE and it's *INCREDIBLY*
> > annoying.
> 
> Debian has done this for quite some time.
> 
> The regular part comes with just the .so's, the ; the -dev portion includes
> the headers and the .a's in case any developers would want to
> statically link.

I learned about it on RH 4.something, rpm distros have been doing it for
quite sometime.  One thing that may hide it is choosing the development
option in the initial install so that the installer automatically
installs the -devel rpms and the user may well be none the wiser.

> 
> > The header files take up very little space - and if they install the
> > library without the headers then it can only be used by binary-only
> > applications.  When you try to install a source-code based project,
> > it *looks* like the library is installed when you ask RPM about it -
> > but in fact it's only halfway installed.
> 
> Without touching on what *should* be done, I believe the intention is
> exactly what you allude to ... install the minimum possible portion of
> the library to allow binaries to run.  Remember packaging for most
> people is all about pre-compiled binaries.
> 
> There are some benefits to this approach.  It minimizes download times
> and hard drive consumption (don't forget that the -dev versions of the
> lib package also include the .a's.)  It gives *most* people exactly
> what they want.
> 
> It's been this way on Debian ever since I can remember so I'm used to
> it and don't think twice about apt-get'ing the -dev portion.
> 
> But, to be fair, there is a downside to this approach (which touches
> on some of the down sides to package management in general.)
> 
> I'll make you a deal: As soon as you come up with a scheme that does
> exactly what *everyone* wants 100% of the time, I'll invest my life
> savings in your company, or vote for you, or do what ever is
> appropriate for your particular scheme. :-)
> 
> Curt.
-- 
Tony Peden <ap...@ea...>