plib-users

Re: [Plib-users] segfault while paste

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

Sebastian Ude wrote:

>>PLIB doesn't participate in Cut/paste operations.  It would be
>>interesting to investigate how to do this portably though.
> 
> Errr ... Steve, it does, but only internally ! That means, you should be
> able to copy-and-paste from a puInput to another, but not from a PUI widget
> to a text field of some X application or vice-versa.

Yes - that's what I meant...but the mechanisms for cut/paste are quite
different between X, Windoze and others.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] segfault while paste

[Sebastian U. <ud...@ha...>]

On Fri, 21 Jun 2002, sjb...@ai... (Steve Baker) wrote:
> Date: Fri, 21 Jun 2002 03:30:45 -0500
> To: Rolf Jakob <Rol...@t-...>
> From: sjb...@ai... (Steve Baker)
> CC: "pli...@li..." <pli...@li...>
> Reply-To: sjb...@ai...
> Subject: Re: [Plib-users] segfault while paste
>
> Rolf Jakob wrote:
>
>
> > How am I supposed to copy text from a puInput widget to the clipboard ?
> > Should there be a way to mark text with either the keyboard or the
> > mouse ? ^C seems to do nothing and ^V breaks with :
>
> PLIB doesn't participate in Cut/paste operations.  It would be
> interesting to investigate how to do this portably though.

Errr ... Steve, it does, but only internally ! That means, you should be
able to copy-and-paste from a puInput to another, but not from a PUI widget
to a text field of some X application or vice-versa.


- Sebastian

Re: [Plib-users] segfault while paste

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

Rolf Jakob wrote:


> How am I supposed to copy text from a puInput widget to the clipboard ?
> Should there be a way to mark text with either the keyboard or the mouse ?
> ^C seems to do nothing and ^V breaks with :

PLIB doesn't participate in Cut/paste operations.  It would be interesting
to investigate how to do this portably though.
  ----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] segfault while paste

[<Rol...@t-...>]

Hello,

How am I supposed to copy text from a puInput widget to the clipboard ?
Should there be a way to mark text with either the keyboard or the mouse ?
^C seems to do nothing and ^V breaks with :

Program terminated with signal 11, Segmentation fault.
Cannot access memory at address 0x4013cdf0
#0  0x809969f in puInput::checkKey (this=0x8145900, key=22) at puInput.cxx:321
321           if ( ( strlen ( getStringValue () ) + strlen ( puGetPasteBuffer 
() ) ) < PUSTRING_MAX - 1 )
(gdb) bt
#0  0x809969f in puInput::checkKey (this=0x8145900, key=22) at puInput.cxx:321
#1  0x8098591 in puGroup::checkKey (this=0x8144a78, key=22, updown=0)
    at puGroup.cxx:156
#2  0x8097af3 in puKeyboard (key=22, updown=0) at pu.cxx:365
#3  0x804cad1 in keyboard (c=22) at wd.cpp:647
#4  0x4002fa59 in ?? ()
#5  0x40030320 in ?? ()
#6  0x40030a3b in ?? ()
#7  0x804dfe0 in main (argc=1, argv=0xbffff974) at wd.cpp:1069
#8  0x402ecb4d in ?? ()
(gdb)

Seems like puGetPasteBuffer() returns an invalid pointer.

Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [Plib-users] Frame Rate down when PUI elements are added

[Michael W. <michael.wessels@z.zgs.de>]

Hi Steve,
I have found in the definition of the subwindows a glutIdleFunc 
statement. This leaded to the low frame rate.

Michael

Steve Baker wrote:

> Michael Wessels wrote:
>
> > I have implemented in my FDS three GUI elements. The effect is, that 
> the
>
>> frame rate is reduced from 84 to 30.
>
>
> Are you using a FNT font or a GLUT font?
>
> GLUT bitmap fonts are not particularly efficient (although that drop 
> seems
> extreme).
>
> My applications show no measurable difference in frame rate even with a
> full menu bar being rendered.
>
> ----------------------------- Steve Baker -------------------------------
> Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
> URLs : http://www.sjbaker.org
>        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
>        http://prettypoly.sf.net http://freeglut.sf.net
>        http://toobular.sf.net   http://lodestone.sf.net
>
>
>

Re: [Plib-users] Frame Rate down when PUI elements are added

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

Michael Wessels wrote:

 > I have implemented in my FDS three GUI elements. The effect is, that the
> frame rate is reduced from 84 to 30.

Are you using a FNT font or a GLUT font?

GLUT bitmap fonts are not particularly efficient (although that drop seems
extreme).

My applications show no measurable difference in frame rate even with a
full menu bar being rendered.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] plib and shadows

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

Rolf Jakob wrote:
> Hello,
> 
> how can I change the material of a leaf that's part of a database imported 
> from AC3D ?
> I traverse all leaves and set the state as following :
> 
>                         state->disable(GL_LIGHTING);
>                         state->disable(GL_BLEND);
>                         state->disable(GL_TEXTURE_2D);
>                         state->setColourMaterial(GL_DIFFUSE);
>                         state->setMaterial(GL_DIFFUSE,0.0f,0.0f,0.0f,0.5f);
>                         state->setShadeModel(GL_FLAT);
> 
> But the leaves are rendered in their colors, so the textures are missing. But 
> what I need is a whole ssgTransform in black. The branch in question was 
> created by a clone(SSG_CLONE_RECURSIVE|SSG_CLONE_STATE).

Can't you just set all of the light sources to black?

Unless you have luminous surfaces, that should work...and luminous
surfaces (arguably) shouldn't cast shadows.

You probably don't want to turn off texturing because something like a
tree could be shaped by the alpha part of the texture.  If you turn off
textures, every tree will cast a neat, perfectly rectangular, shadow!

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] plib and shadows

[<Rol...@t-...>]

some additional notes after trying several things :

On Thursday 13 June 2002 13:07, I wrote:
> Hello,
>
> I'm still trying to get shadows.
That's still true ;-)

> I tried two ways :
> - use a glMultMatrixf((GLfloat *) floorShadow) in the callback function,
> where floorShadow is the projection matrix
> - use a setTransform(floorshadow) before calling ssgCullAndFace
>
> Both don't show a projection, the second shows parts of the scene at a
> different place.
> My guess is the first is superseded by ssg functions and the second is a
> transformation but not a projection. Could that be ?
No. The second way should work, there was a problem in the matrix.
Meanwhile I get a second copy of the scene rendered and I can transform it 
however I like. So far so good. Now I try to switch off texturing (works), 
lighting (works) and replace all colors to a half transparent black. For the 
latter I added two lines to my callback function :
glMaterialfv(GL_FRONT,GL_DIFFUSE,shadowColor);
glColor4f(0.0, 0.0, 0.0, 0.5);
but both seem to be ignored/overwritten.

I think I'm almost there, only this last step is missing.

Any hints ?

Thanks,
Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [Plib-users] plib and shadows

[<Rol...@t-...>]

Hello,

how can I change the material of a leaf that's part of a database imported 
from AC3D ?
I traverse all leaves and set the state as following :

                        state->disable(GL_LIGHTING);
                        state->disable(GL_BLEND);
                        state->disable(GL_TEXTURE_2D);
                        state->setColourMaterial(GL_DIFFUSE);
                        state->setMaterial(GL_DIFFUSE,0.0f,0.0f,0.0f,0.5f);
                        state->setShadeModel(GL_FLAT);

But the leaves are rendered in their colors, so the textures are missing. But 
what I need is a whole ssgTransform in black. The branch in question was 
created by a clone(SSG_CLONE_RECURSIVE|SSG_CLONE_STATE).

Am I missing something ?

Thanks,
Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

[Plib-users] Frame Rate down when PUI elements are added

[Michael W. <michael.wessels@z.zgs.de>]

Hi all,
I have implemented in my FDS three GUI elements. The effect is, that the 
frame rate is reduced from 84 to 30.

What can be the reason for it ?

Michael

Re: [Plib-users] plib and shadows

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

> I'm still trying to get shadows.
> Now I reduced the code so that stencil buffer is not (yet) used, I just want 
> to see the projection of my scene to the ground.
> There is a callback function for predraw which is being called.
> I tried two ways :
> - use a glMultMatrixf((GLfloat *) floorShadow) in the callback function, 
> where floorShadow is the projection matrix

You can't do that because SSG culls the scene to the view frustum prior to
drawing it - so if you go and change the transforms without SSG knowing about
it, you'll get into problems.

 > - use a setTransform(floorshadow) before calling ssgCullAndFace

> Both don't show a projection, the second shows parts of the scene at a 
> different place.
> My guess is the first is superseded by ssg functions and the second is a 
> transformation but not a projection. Could that be ?

Yes - transforms are limited to rotates and translates.  It's not possible
to do bounding sphere culling when the transform is not shape-preserving.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] plib and shadows

[<Rol...@t-...>]

Hello,

I'm still trying to get shadows.
Now I reduced the code so that stencil buffer is not (yet) used, I just want 
to see the projection of my scene to the ground.
There is a callback function for predraw which is being called.
I tried two ways :
- use a glMultMatrixf((GLfloat *) floorShadow) in the callback function, 
where floorShadow is the projection matrix
- use a setTransform(floorshadow) before calling ssgCullAndFace

Both don't show a projection, the second shows parts of the scene at a 
different place.
My guess is the first is superseded by ssg functions and the second is a 
transformation but not a projection. Could that be ?

Thanks,
Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [Plib-users] plib and shadows

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

Rolf Jakob wrote:


>>Well, you can place a draw callback on the top level SGGL node and have
>>it reset the parameters however you like.
> 
> Emm, what do you mean by top level SGGL ? The first leaf in the tree ?

(Oops!  Sorry - that was a brain slip.  My project at work is called SGGL -
I *meant* to say "Top level SSG node" - meaning the root node in the
scene graph - the topmost branch.)

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] plib and shadows

[<Rol...@t-...>]

On Monday 10 June 2002 06:58, Steve Baker wrote:
> Rolf Jakob wrote:
> > As a newbie in OpenGL and plib I searched the web for  possibilities  to
> > have shadows in a scene. I found one simple tutorial for pure OpenGL from
> > a guy at nvidia using the stencil buffer.
>
> Yes - that's not a bad approach - but really all shadow algorithms come
> with some ugly compromises.  Many of the ones that are currently seen in
> games only work because the light source is close to the camera and the
> scene is quite restricted in size.
Yes, I know.  Compared to POVRAY's output it's lame, but it should give my 
scene a more natural look.

> > ssgCullAndDraw() don't seem to work as it's setting up OpenGL  the way it
> > needs it to draw it from the eye's point of view.
>
> Well, you can place a draw callback on the top level SGGL node and have
> it reset the parameters however you like.

Emm, what do you mean by top level SGGL ? The first leaf in the tree ?

Thanks,
Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [Plib-users] plib and shadows

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

Rolf Jakob wrote:


> As a newbie in OpenGL and plib I searched the web for  possibilities  to have 
> shadows in a scene. I found one simple tutorial for pure OpenGL from a guy at 
> nvidia using the stencil buffer.

Yes - that's not a bad approach - but really all shadow algorithms come with
some ugly compromises.  Many of the ones that are currently seen in games only
work because the light source is close to the camera and the scene is quite
restricted in size.

> Now, this requires to draw the scene twice - one for the projection on the 
> ground and one to actually show the scene. It's working fine with an object 
> created using OpenGL directly, but I would like to use modelled scenes from 
> AC3d and benefit from plib's features.
> 
> Is it possible to make SSG draw the scene with some settings and 
> transformation and stencil buffer, so that the shadows can be calculated ?

Yes.

> ssgCullAndDraw() don't seem to work as it's setting up OpenGL  the way it 
> needs it to draw it from the eye's point of view.

Well, you can place a draw callback on the top level SGGL node and have
it reset the parameters however you like.

> Maybe there are other ways to get shadows with plib ?

Not that I know of.

I do mostly outdoor games - and I generally just plant a fuzzy blob under
the things that need shadows.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

[Plib-users] plib and shadows

[<Rol...@t-...>]

Hi,

As a newbie in OpenGL and plib I searched the web for  possibilities  to have 
shadows in a scene. I found one simple tutorial for pure OpenGL from a guy at 
nvidia using the stencil buffer.
Now, this requires to draw the scene twice - one for the projection on the 
ground and one to actually show the scene. It's working fine with an object 
created using OpenGL directly, but I would like to use modelled scenes from 
AC3d and benefit from plib's features.

Is it possible to make SSG draw the scene with some settings and 
transformation and stencil buffer, so that the shadows can be calculated ?
ssgCullAndDraw() don't seem to work as it's setting up OpenGL  the way it 
needs it to draw it from the eye's point of view.
Maybe there are other ways to get shadows with plib ?

Thanks in Advance,
Rolf
-- 
Rolf Jakob at home (rj...@du...)
WWW : http://www.franken.de/users/duffy1/rjakob (KDE-Utils and CCS)

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

[Arnt K. <ar...@c2...>]

On Thu, 06 Jun 2002 21:06:36 +0200, 
Sebastian Ude <ud...@ha...> wrote in message 
<E17...@mx...>:

> 
> 
> On Thu, 06 Jun 2002, de...@es... (Ferréol de SORAS) wrote:
> > Date: Thu, 06 Jun 2002 20:36:02 +0300
> > To: pli...@li...
> > From: de...@es... (Ferréol de SORAS)
> > Subject: Re: [Plib-users] problem     (with plib) while installing
> > SimGear(FlightGear)
> >
> > well i followed instructions from howtows to install glut and it
> > works pretty well (for ex, tuxracer works)...
> 
> Okay, at least you read the docs. A very good decision, in deed - many
> users don't, and wonder afterwards why their systems are messed up.

..the commonly accepted way is to place "all foreign code" in 
'/usr/local/', and use the distros own tools to mess around 
everywhere else.

> But please make notes of what new files you copied to your system -
> the notes might get in handy if you need to remove something later or
> just wonder what package a particular file belongs to. Or even better:
> Compile the stuff, then make a RPM / debian / slackware package out of
> it and install the package.
> 
> 
> > it is not the problem the problem might be what wonders you !
> 
> Well, I really doubt that this is a bug in the SimGear configure
> script. This project is too popular to have still significant bugs in
> a often-used thing like the configure system - but you never know ...
> 
> 
> > (i did not find slackware rpms for glut)
> 
> First, doesn't use slackware its own package format ?
> 
> Secondly, I'd say there must be packages for slackware. It is really
> is not a that unpopular linux distribution - did google really not
> find anything ?

..the "first" packaged distro, dates back to the mid 90-ies, uses 
binary tarballs with scripts, typically named like binary-0.1.2.tgz 
or somesuch.  Some people swear by it, and at Red Hat and Debian. ;-)
 
> Anyway, compiling from source on your own is basically okay, as long
> as you
> 
> - remove versions of the program / library that your distribution
> installed
>   prior to installing something manually. Almost all Makefiles won't
>   save you from having two different versions of the same library
>   installed on the same system in differernt paths, which is a very
>   bad thing that can lead to the obscurest problems.
> 
> - read the docs !

..hear, hear!!!

> - diligently take notes of what files you installed on your system.
> There
>   most likely will be a situation where you will be happy that you
>   did. Note that programs such as installwatch (use google) can help
>   you with doing so.
> 
> - remember to remove the files you installed manually prior to
> installing
>   a RPM / debian / slackware package of the software again. Good that
>   you took the notes upon installing, eh ?
> 
> Furthermore, note that most package managers do the above
> automatically for you, so I consider them a very good thing especially
> for novice users. When used correctly, they save you from a great
> amount of human mistakes, while there is almost zero protection when
> installing something manually.
> 
> 
> But to come back to the original topic: Did you do the "find" ? Where
> do the header files reside ?
> 
> 
> - Sebastian


-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)
...with a number of polar bear hunters in his ancestry...
  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

[Sebastian U. <ud...@ha...>]

On Wed, 05 Jun 2002, sjb...@ai... (Steve Baker) wrote:
> Date: Wed, 05 Jun 2002 19:49:26 -0500
> To: ud...@ha...
> From: sjb...@ai... (Steve Baker)
> CC: pli...@li...
> Reply-To: sjb...@ai...
> Subject: Re: [Plib-users] problem   (with plib) while installing 
> SimGear(FlightGear)
>
> Sebastian Ude wrote:
>
> > But it does not help anyone to confuse end-users by telling them that
> > their distribution put the OpenGL files at the wrong place.
>
> Sure it helps them - it allows them to put the files in the right place -
> and not have continual problems with installing new software that can't
> find the headers.

Hm, that's true !


> Yes - but it does no good for me to go by myself to the distro maker and
> complain.
>
> It has to be all their customers who complain.  I don't use either of the
> two offending distro's.

Neither I do. But I would recommend affected users to file bug reports to
the distribution makers - isn't it considered a bug if a distribution
violates well-known filesystem hirarchie standards ?


- Sebastian

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

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

Sebastian Ude wrote:

> But it does not help anyone to confuse end-users by telling them that their
> distribution put the OpenGL files at the wrong place.

Sure it helps them - it allows them to put the files in the right place - and not have
continual problems with installing new software that can't find the headers.

> It are the distribution makers that must be blamed.

Yes - but it does no good for me to go by myself to the distro maker and complain.

It has to be all their customers who complain.  I don't use either of the two
offending distro's.

Meanwhile, we have to fix the problem one user at a time.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
        http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
        http://prettypoly.sf.net http://freeglut.sf.net
        http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

[Sebastian U. <ud...@ha...>]

On Wed, 05 Jun 2002, sjb...@ai... (Steve Baker) wrote:
> Date: Wed, 05 Jun 2002 18:46:01 -0500
> To: ud...@ha...
> From: sjb...@ai... (Steve Baker)
> CC: pli...@li...
> Reply-To: sjb...@ai...
> Subject: Re: [Plib-users] problem   (with plib) while installing 
> SimGear(FlightGear)

[...]

> At the risk of repeating myself...
>
>   glut.h, gl.h, glext.h, glu.h ...and all their little friends
>   belong in one place - and one place only:
>
>      /usr/include/GL
>
> ....if you see them anywhere else - remove them.
>
> If you don't do that then some programs (which happen to be tolerant)
> will find them - and others (which happen to be pedantic) will not.
>
> Similarly with the library files - which should be in /usr/lib/ and
> nowhere else.

As I said, Steve:

"[...] /usr/include/GL/, /usr/local/include/GL/ or /usr/X11R6/include/GL/,
then everything should be fine (well, in the last case Steve might argue
that things are not fine [...]"

But it does not help anyone to confuse end-users by telling them that their
distribution put the OpenGL files at the wrong place. It are the
distribution makers that must be blamed.


- Sebastian

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

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

Sebastian Ude wrote:

> If the file shows up either in /usr/include/GL/, /usr/local/include/GL/ or
> /usr/X11R6/include/GL/, then everything should be fine (well, in the last
> case Steve might argue that things are not fine - but as I can see from the
> gcc commandline in the logs, /usr/X11R6/include/ is added to the
> searchpatch, so there is no need for you to care about this issue for
> now.).

At the risk of repeating myself...

  glut.h, gl.h, glext.h, glu.h ...and all their little friends
  belong in one place - and one place only:

     /usr/include/GL

...if you see them anywhere else - remove them.

If you don't do that then some programs (which happen to be tolerant)
will find them - and others (which happen to be pedantic) will not.

Similarly with the library files - which should be in /usr/lib/ and
nowhere else.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://www.sjbaker.org
       http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net
       http://prettypoly.sf.net http://freeglut.sf.net
       http://toobular.sf.net   http://lodestone.sf.net

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

[Sebastian U. <ud...@ha...>]

On Thu, 06 Jun 2002, de...@es... (Ferr=E9ol de SORAS) wrote:
> Date: Thu, 06 Jun 2002 22:22:52 +0300
> To: pli...@li...
> From: de...@es... (Ferr=E9ol de SORAS)
> Subject: Re: [Plib-users] problem      (with plib) while installing
> SimGear(FlightGear)
>
> problem ended
>
> i created a symbolic link to the glut headers directory in the place
> most program would like to find them, and it works perfectly

Certainly a good idea - gcc doesn't by default search for header files in
/usr/src/somepackage-whateverversion/, and by the way - since you
mentitoned having tried that - as far as I know SimGear doesn't support t=
he
--with-GL option as PLIB does.

As I said: I bet if you used the packages that came with your distributio=
n,
that is, if you put everything at the right place in case you compiled GL=
UT
yourself, SimGear would have configure'd flawlessly ...


> (now the problem is with FlightGear install, but it is another mailing
> list)

Yes.


> a least i have learnt something : information in log files are more
> significant than information from standards outputs, because standard
> output said it was a problem with plib, and it wasn't...

Right. What matters is the actual compiler output - configure just tells
you that the compiler test failed, but not why.

However, configure did not say that there was a problem with PLIB. This i=
s
your interpretition. It just said that it could not compile a simple
program that includes the pu.h header file, which may mean that there is =
a
problem with the PLIB installation, but also that something is wrong with
one of PLIB's direct or indirect dependancies.

That is the reason why you are right when saying that "information in log
files are more significant than information from standard outputs".


- Sebastian

Re: [Plib-users] problem =?iso-8859-1?q?=28with_plib=29?= while installing =?iso-8859-1?q?SimGear=28FlightGear=29?=

[de S. <de...@es...>]

problem ended

i created a symbolic link to the glut headers directory in the place
most program would like to find them, and it works perfectly

(now the problem is with FlightGear install, but it is another mailing
list)

a least i have learnt something : information in log files are more
significant than information from standards outputs, because standard
output said it was a problem with plib, and it wasn't...


many thanks to you, sebastian

-------------------
> 
> 
> On Thu, 06 Jun 2002, de...@es... (Ferréol de SORAS) wrote:
> > Date: Thu, 06 Jun 2002 20:36:02 +0300
> > To: pli...@li...
> > From: de...@es... (Ferréol de SORAS)
> > Subject: Re: [Plib-users] problem     (with plib) while installing
> > SimGear(FlightGear)
> >
> > well i followed instructions from howtows to install glut and it
works
> > pretty well (for ex, tuxracer works)...
> 
> Okay, at least you read the docs. A very good decision, in deed -
many
> users don't, and wonder afterwards why their systems are messed up.
> 
> But please make notes of what new files you copied to your system -
the
> notes might get in handy if you need to remove something later or
just
> wonder what package a particular file belongs to. Or even better:
Compile
> the stuff, then make a RPM / debian / slackware package out of it
and
> install the package.
> 
> 
> > it is not the problem the problem might be what wonders you !
> 
> Well, I really doubt that this is a bug in the SimGear configure
script.
> This project is too popular to have still significant bugs in a
often-used
> thing like the configure system - but you never know ...
> 
> 
> > (i did not find slackware rpms for glut)
> 
> First, doesn't use slackware its own package format ?
> 
> Secondly, I'd say there must be packages for slackware. It is really
is not
> a that unpopular linux distribution - did google really not find
anything ?
> 
> 
> Anyway, compiling from source on your own is basically okay, as long
as you
> 
> - remove versions of the program / library that your distribution
installed
>   prior to installing something manually. Almost all Makefiles won't
save
>   you from having two different versions of the same library
installed on
>   the same system in differernt paths, which is a very bad thing
that can
>   lead to the obscurest problems.
> 
> - read the docs !
> 
> - diligently take notes of what files you installed on your system.
There
>   most likely will be a situation where you will be happy that you
did.
>   Note that programs such as installwatch (use google) can help you
with
>   doing so.
> 
> - remember to remove the files you installed manually prior to
installing
>   a RPM / debian / slackware package of the software again. Good
that you
>   took the notes upon installing, eh ?
> 
> Furthermore, note that most package managers do the above
automatically for
> you, so I consider them a very good thing especially for novice
users. When
> used correctly, they save you from a great amount of human mistakes,
while
> there is almost zero protection when installing something manually.
> 
> 
> But to come back to the original topic: Did you do the "find" ?
Where do
> the header files reside ?
> 
> 
> - Sebastian
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas --
http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
Ferréol de Soras

Re: [Plib-users] problem (with plib) while installing SimGear(FlightGear)

[Sebastian U. <ud...@ha...>]

On Thu, 06 Jun 2002, de...@es... (Ferréol de SORAS) wrote:
> Date: Thu, 06 Jun 2002 20:36:02 +0300
> To: pli...@li...
> From: de...@es... (Ferréol de SORAS)
> Subject: Re: [Plib-users] problem     (with plib) while installing
> SimGear(FlightGear)
>
> well i followed instructions from howtows to install glut and it works
> pretty well (for ex, tuxracer works)...

Okay, at least you read the docs. A very good decision, in deed - many
users don't, and wonder afterwards why their systems are messed up.

But please make notes of what new files you copied to your system - the
notes might get in handy if you need to remove something later or just
wonder what package a particular file belongs to. Or even better: Compile
the stuff, then make a RPM / debian / slackware package out of it and
install the package.


> it is not the problem the problem might be what wonders you !

Well, I really doubt that this is a bug in the SimGear configure script.
This project is too popular to have still significant bugs in a often-used
thing like the configure system - but you never know ...


> (i did not find slackware rpms for glut)

First, doesn't use slackware its own package format ?

Secondly, I'd say there must be packages for slackware. It is really is not
a that unpopular linux distribution - did google really not find anything ?


Anyway, compiling from source on your own is basically okay, as long as you

- remove versions of the program / library that your distribution installed
  prior to installing something manually. Almost all Makefiles won't save
  you from having two different versions of the same library installed on
  the same system in differernt paths, which is a very bad thing that can
  lead to the obscurest problems.

- read the docs !

- diligently take notes of what files you installed on your system. There
  most likely will be a situation where you will be happy that you did.
  Note that programs such as installwatch (use google) can help you with
  doing so.

- remember to remove the files you installed manually prior to installing
  a RPM / debian / slackware package of the software again. Good that you
  took the notes upon installing, eh ?

Furthermore, note that most package managers do the above automatically for
you, so I consider them a very good thing especially for novice users. When
used correctly, they save you from a great amount of human mistakes, while
there is almost zero protection when installing something manually.


But to come back to the original topic: Did you do the "find" ? Where do
the header files reside ?


- Sebastian

Re: [Plib-users] problem =?iso-8859-1?q?=28with_plib=29?= while installing =?iso-8859-1?q?SimGear=28FlightGear=29?=

[de S. <de...@es...>]

well i followed instructions from howtows to install glut and it works
pretty well (for ex, tuxracer works)... it is not the problem
the problem might be what wonders you !

(i did not find slackware rpms for glut)


-------------------
> 
> 
> On Thu, 06 Jun 2002, de...@es... (Ferréol de SORAS) wrote:
> > Date: Thu, 06 Jun 2002 19:18:49 +0300
> > To: pli...@li...
> > From: de...@es... (Ferréol de SORAS)
> > Subject: Re: [Plib-users] problem    (with plib) while installing
> > SimGear(FlightGear)
> >
> > well in fact i compiled plib with
> >
> > "./configure --with-GL=/usr/src/glut-3.7" so that plib found my
opengl
> > directory because it dit not find it by default
> 
> Didn't you say that you do not know linux very well ? Then PLEASE,
PLEASE
> do not try to compile Mesa or GLUT yourself. Use the appropiate
packages
> supplied with your distribution (there are some, really).
> 
> Being a non-experienced user, you risk messing up your system
otherwise.
> Even as an experienced user, you mess up your systems package
handling
> unless you tell the RPM (I assume that your distribution is
RPM-based)
> database about what you installed in some way.
> 
> I bet if you had used the packages that came with your linux
distribution,
> SimGear had ./configure'd flawlessly. The best thing is if you try
to
> remove the libraries and header files you installed manually from
your
> system (if you know approximately when you did the install, find
-cmin
> helps - see "man find" for details) and install the corresponding
RPM
> packages afterwards.
> 
> 
> > after you told me to look at the log, i remarked there was a
problem
> > with glut and i tried to configure simgear unsuccessfully with the
> > same argument, but it did not work
> >
> > i'll try to copy my gl files in several directories untill it
works
> > :-)
> >  (or link the dir)
> 
> No, please also don't do that.
> 
> 
> > the stupid fact is the configure script which says there is a
problem
> > with plib whereas it is with gl dir.....
> 
> Well - the configure program tries to compile a simple program that
> includes pu.h. If the compilation process failes, then this does not
> necessarily mean that the pu.h header file is missing or that
something is
> wrong with it - it could also be any of the header files included by
it
> directly or indirectly.
> 
> What wonders *me* is that when the Simgear configure script checks
for
> GLUT, no error ocourrs, while the compiler obviously cannot find the
GLUT
> header fine when checking for pu.h.
> 
> 
> - Sebastian
> 
> _______________________________________________________________
> 
> Don't miss the 2002 Sprint PCS Application Developer's Conference
> August 25-28 in Las Vegas --
http://devcon.sprintpcs.com/adp/index.cfm
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> https://lists.sourceforge.net/lists/listinfo/plib-users
> 
Ferréol de Soras