plib-users

[Plib-users] can't compile 1.5.1

[Marvin M. <m.m...@we...>]

Hi!

I can't compile plib 1.5.1. Looks like the file "ssgLoadVRML.h" (not 
sure, I don't have internet access from my Linux workstation, so I have 
to write from another computer) is missing.

Can anyone help?

TIA

Marvin

[Plib-users] ssgStripify generates bad normals?

[Jeff L. <lo...@ke...>]

I'm using plib 1.4.2.  I'm loading an ASE file that contains the
following vertices:

*MESH_VERTEX_LIST {
	*MESH_VERTEX    0       11.0784 42.2896 3.2353
        *MESH_VERTEX    1       21.0784 42.2896 3.2353
        *MESH_VERTEX    2       11.0784 42.2896 13.2353
        *MESH_VERTEX    3       21.0784 42.2896 13.2353
        *MESH_VERTEX    4       11.0784 32.2896 3.2353
        *MESH_VERTEX    5       21.0784 32.2896 3.2353
        *MESH_VERTEX    6       11.0784 32.2896 13.2353
        *MESH_VERTEX    7       21.0784 32.2896 13.2353
        }

The vertices make up a cube (which is the only thing in the ASE file). 
I can send the entire 3KB ASE file if anyone is interested.  Anyway,
after loading this into my program and calling ssgStripify on it I find
that the normals for the vertices come out to be:

V0) { 11.078, 42.290, 13.235 } N0) { -0.816, 0.408, 0.408 }
V1) { 11.078, 32.290, 13.235 } N1) { -0.408, -0.408, 0.816 }
V2) { 21.078, 42.290, 13.235 } N2) { 0.333, 0.667, 0.667 }
V3) { 21.078, 32.290, 13.235 } N3) { 0.667, -0.667, 0.333 }
V4) { 21.078, 42.290, 3.235 } N4) { 0.816, 0.408, -0.408 }
V5) { 21.078, 32.290, 3.235 } N5) { 0.408, -0.408, -0.816 }
V6) { 11.078, 42.290, 3.235 } N6) { -0.333, 0.667, -0.667 }
V7) { 11.078, 32.290, 3.235 } N7) { -0.667, -0.667, -0.333 }

By my calculations all the normals should be of the form:

+/- 0.667, +/- 0.667, +/- 0.667


Can anyone explain what I'm calculating wrong or why the normals that
PLIB calculates are more correct than the normals I've calculated? 
Perhaps the ASE file isn't generating the cube that I think it is?

Thanks,
Jeff Long

Re: [Plib-users] Couple of fntRenderer questions

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

Steve Baker wrote:

> > but is there a way to do rotated text (vertical in particular) with fntRenderer/fntTexFont
> > in 1.5.1?
> 
> Yes....how about:  glRotatef   :-)
> 
> Try (for example) adding the following two lines to the end of 'setOpenGLState' in the
> PLIB example program 'examples/src/fnt/fnt_test.cxx' and the text will spin quite happily.

Ooops!  Sorry - I forgot the two lines!

   static float a = 0 ;
   glRotatef ( a += 0.1, 0, 0, 1 ) ;

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] Couple of fntRenderer questions

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

Jason Steele wrote:

> I hope I'm not missing something obvious here...

Yep - you are.

> but is there a way to do rotated text (vertical in particular) with fntRenderer/fntTexFont
> in 1.5.1?

Yes....how about:  glRotatef   :-)

Try (for example) adding the following two lines to the end of 'setOpenGLState' in the
PLIB example program 'examples/src/fnt/fnt_test.cxx' and the text will spin quite happily.

In general, the text is drawn relative to the origin in the Z==0 plane - but all of the
usual OpenGL modelview transformations will work so you can apply text to 3D objects
and do all sorts of other amusing tricks.

>  (I'm using fnt.h, but not PUI)

Good - PUI doesn't really support rotated things - but
raw FNT does.
 
> Also, other than the GL_TEXTURE_2D, is there any other effect on the
> OpenGL state that has to be undone after a begin()/puts()/end()
> sequence?   Is there a cleaner way to restore the state other than
> an explicit glDisable(GL_TEXTURE_2D) after I do my font rendering?

State management in OpenGL is a pain.  You can use glPushAttrib/glPopAttrib
to save and restore state - but it's quite slow.

Similarly, saving and restoring state can be quite inefficient if it's
done 'strictly by the book'...glGet{anything} is extremely slow - so
you really have to remember what state you have in your own code and
restore it after.

There really isn't a single 'good' way to do this  :-(
 
> Finally, is there a way to query the inter-line space from either the
> font or the renderer?  getBBox() doesn't quite do what I need.  I see
> in the source there's a hardcoded 1.333*point size increment of the
> cursor's y position for a '\n' (that's the quantity I'm after)
> Is there a way to get this without hardcoding the 1.333 in my
> code?  If not, can I put in a request for this value to be exposed
> through the interface? (allowing modification of it as well would be
> a bonus

There isn't a way to do that right now...there was no way to read out
the amount of 'inter-line-gap' from the TXF file - so I had to choose a
'reasonable' value.  My father was a professional printer - and he said
that a third of the total height of the line is a reasonable rule of thumb.

The best bet is not to let FNT handle the '\n' but to do it yourself and
use glTranslate to position the text.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] Couple of fntRenderer questions

[Jason S. <tam...@ai...>]

[Apologies if this is a re-send - SourceForge's lists don't seem to like
the way I normally send mail.]

Howdy,

I hope I'm not missing something obvious here, but is there a way to
do rotated text (vertical in particular) with fntRenderer/fntTexFont
in 1.5.1?  (I'm using fnt.h, but not PUI)

Also, other than the GL_TEXTURE_2D, is there any other effect on the
OpenGL state that has to be undone after a begin()/puts()/end()
sequence?   Is there a cleaner way to restore the state other than
an explicit glDisable(GL_TEXTURE_2D) after I do my font rendering?

Finally, is there a way to query the inter-line space from either the
font or the renderer?  getBBox() doesn't quite do what I need.  I see
in the source there's a hardcoded 1.333*point size increment of the
cursor's y position for a '\n' (that's the quantity I'm after)
Is there a way to get this without hardcoding the 1.333 in my
code?  If not, can I put in a request for this value to be exposed
through the interface? (allowing modification of it as well would be 
a bonus)

Thanks,
        -Jason Steele (kudzu)

Re: [Plib-users] enter / leave events for puButtons ?

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

Sebastian Ude wrote:
 
> Is there an easy way to invoke a callback whenever the mouse pointer enters
> or leaves the area of a puButton ?

PUI wasn't designed to allow that - I suppose you could cheat and in the
motion callback, pass button-is-down values to PUI even when the button
is really up - then in your PUI widget's callback, check whether the
button is *REALLY* pressed down and only take the appropriate action
when it is.

That would require that you set puObject::setActiveDirn ( PU_CONTINUAL )
or something like that.

> I tink of keeping track of the button positions and compare the cursor
> position with the collected positions in my motion callback - but isn't
> there a less difficult way ?

Well, the way I suggest is still rather ugly - but I think it'll work.
Try it in a simple test environment before you start to rely on it!

This kind of 'mouse-over' highlighting is becoming rather popular
(dunno why) - perhaps we should consider extending PUI to do it
properly with a 'mouse-over' callback?

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] enter / leave events for puButtons ?

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

Is there an easy way to invoke a callback whenever the mouse pointer enters
or leaves the area of a puButton ?

I tink of keeping track of the button positions and compare the cursor
position with the collected positions in my motion callback - but isn't
there a less difficult way ?


Thanks

Sebastian Ude

Re: [Plib-users] Re: Intersection Testing / 3ds loading

[Wolfram K. <w_...@rz...>]

Thomas, which format were the files that PLIB didn't read? Do you want
to send one to me?

"Thomas Gahr" <pin...@we...> wrote:

>No, I'm not talking about accessing the VtxTables (I DO KNOW HOW TO DO =
IT!!!)=20
>I want to find out how to access the VtxTables IN THE ssgEntity,=20
>in wich I loaded my model to.

You have to recursively walk the scene graph that the loaders returns
to you.

>How can I find out the angle between the direction vector of my player=20
>and the plane I crashed into? (for sliding along)

You can calculate the normal "n" of the wall by using the vector
product ("Kreuzprodukt" in German) of the edges of the polygon.
If v is the old velocity, calculate a scalar factor "f" by doing
v*n / n*n. The new velocity is then v+f*n. f is calculated so that=20
v+f*n is perpendicular to n.

Bye bye,
Wolfram.

[Plib-users] Re: Intersection Testing / 3ds loading

[Thomas G. <pin...@we...>]

No, I'm not talking about accessing the VtxTables (I DO KNOW HOW TO DO =
IT!!!) I want to find out how to access the VtxTables IN THE ssgEntity, =
in wich I loaded my model to.

Well, if I  set the radius of the sphere to 2.0f the prog starts, grey =
screen ->short flashing scene (if you're fast enough you can see it) and =
then segmentation fault.

But did I do anything worng in my code? Another interesting thing: How =
can I find out the angle between the direction vector of my player and =
the plane I crashed into? (for sliding along)

Re: [Plib-users] Intersection Testing / 3ds loading

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

> Thomas Gahr wrote:
> 
> I am writing a game with PLIB it's a kind of 3d jump n run (like "tux a quest fo herring"). First I used heightmaps (modified majik-example), but now I wanted to use models for my terrain.
> I made some models using anim8or and tried to load them.

What file format does anim8or write?

> Most of them were white, although I applied materials and if i applied textures
> they were stretched over the whole model (but I think that's a problem in anim8or).

...or the PLIB file loader for whatever format you are using.

> Can I apply states to ssgEntities?

No - only ssgLeaf nodes.

> How can I modify the VtxTables (or whatever the loader uses to store
> the veritces) of the model I loaded?

RTFM!  There is API for ssgVtxTable that allows access to the vertex tables
themselves.

> Now (that I have models for the terrain with some walls and steep planes) I wanted to use the
> LOS-intersection testing for checking if I am running against a wall.

TuxAQFH and TuxKart both use bounding sphere intersection tests for that - it works much better
than the alternatives.

> Then I tried the Isect-method with a sphere:
> 
>     sgVec3 test_vec ;
>     sgMat4 invmat ;
>     sgMakeIdentMat4 ( invmat ) ;
>     sgSphere *sphere;
> 
>     invmat[3][0] = -pos[0] ;
>     invmat[3][1] = -pos[1] ;
>     invmat[3][2] = -(pos[2]+1.5) ;
> 
>     sphere = new sgSphere;
> 
>     sphere->setCenter(0.0,0.0,1.2);
>     sphere->setRadius(1.0);
> 
>     ssgHit *results ;
>     int num_hits = ssgIsect ( tscene, sphere, invmat, &results ) ;
> 
>     float ehot = -1000000.0f ;
> 
>     for ( int i = 0 ; i < num_hits ; i++ )
>     {
>       ssgHit *eh = &results [ i ] ;
> 
>       float ehgt = - eh->plane[3] / eh->plane[2] ;
>       if ( ehgt >= ehot )
>         ehot = ehgt ;
>     }
> The Program crashes when I increase the sphere's radius

That's rather suprising - where exactly does it die?

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] Intersection Testing / 3ds loading

[Thomas G. <pin...@we...>]

I am writing a game with PLIB it's a kind of 3d jump n run (like "tux a =
quest fo herring"). First I used heightmaps (modified majik-example), =
but now I wanted to use models for my terrain.
I made some models using anim8or and tried to load them. Most of them =
were white, although I applied materials and if i applied textures they =
were stretched over the whole model (but I think that's a problem in =
anim8or). Can I apply states to ssgEntities? How can I modify the =
VtxTables (or whatever the loader uses to store the veritces) of the =
model I loaded?

Problem No. 2:

Intersection Testing. The HOT-Testing works fine, I've always been doing =
it like this:

  invmat[3][0] =3D -ppos.xyz[0] ;
  invmat[3][1] =3D -ppos.xyz[1] ;
  invmat[3][2] =3D  0.0f          ;

  test_vec [0] =3D 0.0f ;
  test_vec [1] =3D 0.0f ;
  test_vec [2] =3D 100000.0f ;

  ssgHit *results ;
  int num_hits =3D ssgHOT ( tscene, test_vec, invmat, &results ) ;

  phits=3Dnum_hits;

  float hot =3D -1000000.0f ;


  for ( i =3D 0 ; i < num_hits ; i++ )
  {
    ssgHit *h =3D &results [ i ] ;

    float hgt =3D - h->plane[3] / h->plane[2] ;

    if ( hgt >=3D hot )
      hot =3D hgt ;
  }

Now (that I have models for the terrain with some walls and steep =
planes) I wanted to use the LOS-intersection testing for checking if I =
am running against a wall.
But it didn't work. I tried it this way:

    sgVec3 test_vec ;
    sgMat4 invmat ;
    sgMakeIdentMat4 ( invmat ) ;

    invmat[3][0] =3D -pos[0] ;
    invmat[3][1] =3D -pos[1] ;
    invmat[3][2] =3D -(pos[2]+1.5) ;

    test_vec [0] =3D 2.0*sin(turn*M_PI/180.0) ;
    test_vec [1] =3D 2.0*cos(turn*M_PI/180.0) ;
    test_vec [2] =3D 1.5 ;

    ssgHit *results ;
    int num_hits =3D ssgIsect ( tscene, sphere, invmat, &results ) ;

    float ehot =3D -1000000.0f ;

    for ( int i =3D 0 ; i < num_hits ; i++ )
    {
      ssgHit *eh =3D &results [ i ] ;

      float ehgt =3D - eh->plane[3] / eh->plane[2] ;

      if ( ehgt >=3D ehot )
        ehot =3D ehgt ;
    }

But it only showed my player's z-distance to the terrain and the normals =
of the polygons I am running on (I guess).
Well, very useful, too, but I wanted to know if my player is running =
against a wall (if the vector test_vec touches a plane).

What do I have to change?

Then I tried the Isect-method with a sphere:

    sgVec3 test_vec ;
    sgMat4 invmat ;
    sgMakeIdentMat4 ( invmat ) ;
    sgSphere *sphere;

    invmat[3][0] =3D -pos[0] ;
    invmat[3][1] =3D -pos[1] ;
    invmat[3][2] =3D -(pos[2]+1.5) ;

    sphere =3D new sgSphere;

    sphere->setCenter(0.0,0.0,1.2);
    sphere->setRadius(1.0);

    ssgHit *results ;
    int num_hits =3D ssgIsect ( tscene, sphere, invmat, &results ) ;

    float ehot =3D -1000000.0f ;

    for ( int i =3D 0 ; i < num_hits ; i++ )
    {
      ssgHit *eh =3D &results [ i ] ;

      float ehgt =3D - eh->plane[3] / eh->plane[2] ;

      if ( ehgt >=3D ehot )
        ehot =3D ehgt ;
    }

The Program crashes when I increase the sphere's radius, and plane[0] =
and plane[1] (A and B in the equation, I guess) change with the =
direction my player is looking in, plane[2 and 3] don't change. But the =
sphere touches neither the ground nor any other part of my scene.

Sorry for the long mail, but I am pretty in despair.

Cheeers, Thomas Gahr

[Plib-users] Re: flightgear problem

[Stephen L. <le...@na...>]

For those of you who get the "ssgInit called without a valid OpenGL
context"
message when trying to run FlghtGear try the following test
program which illustrates a problem in libGL on some systems.
Stephen Lewis

Re: [Plib-users] Re: flightgear problem

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

Steve Wendt wrote:
 
> I've never had that problem using RH 7.0 or 7.1, but as I've said, I build my
> own Mesa, with glide support.  No error in software mode or glide mode.

Sorry - yes - I should have been clearer.

The versions of Mesa that use GLIDE don't use Xfree for-real - they have *fake* GLX
calls.  If you look into the Mesa sources, you see things like:

XVisualInfo *glXChooseVisual( Display *dpy, int screen, int *list )
{
#ifdef REALGLX
   if (display_has_glx(dpy))
      return Real_glXChooseVisual( dpy, screen, list );
   else
#endif
      return Fake_glXChooseVisual( dpy, screen, list );
}

...so you don't have the problem.  I think we'll only see it with DRI-Mesa's.

> >The issue belongs (IMHO) in the Mesa mailing list...
> 
> Perhaps - but maybe those with the problem should try building Mesa
> themselves, if they haven't already?

Well, I think it's more to do with you using GLIDE than to do with
building it yourself.
 
----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] Re: flightgear problem

[Steve W. <st...@sh...>]

On Sat, 01 Sep 2001 18:32:25 -0500, Steve Baker wrote:

>  * Up until today, every instance of the problem had been on
>    systems running Mesa under RH 7.x or Mandrake 8.x.  I've never
>    heard of such a system that worked - or of any other system that

I've never had that problem using RH 7.0 or 7.1, but as I've said, I build my 
own Mesa, with glide support.  No error in software mode or glide mode.

>The issue belongs (IMHO) in the Mesa mailing list...

Perhaps - but maybe those with the problem should try building Mesa 
themselves, if they haven't already?

>What Xfree version are you all running?  Is anyone else running that
>version with the same version of Mesa and NOT seeing the problem?

I successfully use 3.3.6 and 4.02 with Mesa 3.4.2.


-----------
"Good people do not need laws to tell them to act responsibly,
while bad people will find a way around the laws."
     - Plato (427-347 B.C.)

Re: [Plib-users] Re: flightgear problem

[Stephen L. <le...@na...>]

Steve Baker,
Thank you for a good answer. Response embedded...
Stephen Lewis

Steve Baker wrote:
> 
> Stephen Lewis wrote:
> >
> > Gentlemen,
> > I have joined this list because I have the "flightgear" problem.
> > I have just read a weeks worth of discussion concerning the
> > "ssgInit called without a valid OpenGL context". I tried to compile
> > FlighGear 0.7.8 on a PowerPC running YellowDogLinux 2.0.
> > Although based on RH 7 there is no MMX and the compiler is 2.95.3
> 
> That's interesting new information.  Which OpenGL version do you have?

I believe GL version 1.2 from Mesa 3.4

> 
> > There has been much speculation and not much science in this discussion.
> 
> Well, there has been science to the extent that I personally can provide
> science.  The facts I have to date are:
> 
>   * glXGetCurrentContext is returning NULL
>   * ...which is *SUPPOSED* to mean that there isn't a
>     valid OpenGL rendering context.
>   * But we demonstrably *DO* have a rendering context at that
>     point because we can comment out the glXGetCurrentContext and
>     the program runs correctly.
>   * The exact same sequence of instructions when run on other OpenGL
>     implementations (eg nVidia's) and/or other windowing systems (eg Windoze)
>     and/or different C++ compilers (eg 2.95.2) *DOES* result in a valid
>     result from glXGetCurrentContext.
>   * This same problem shows up in other OpenGL programs that test
>     glXGetCurrentContext...not just PLIB programs.
>   * Up until today, every instance of the problem had been on
>     systems running Mesa under RH 7.x or Mandrake 8.x.  I've never
>     heard of such a system that worked - or of any other system that
>     didn't work.
> 
> So, what are we to deduce from these facts?
> 
> I'm inclined to believe therefore that this is some kind of an underlying
> bug in the windowing system or OpenGL implementation...probably the latter...
> caused by *something* unique to RH implementations (and other systems that
> share something with it).
> 
> I'm currently working under the presumption that the "known-to-be-dubious"
> C++ compiler (GCC 2.96/2.97) is mis-compiling Mesa in some subtle manner
> that causes glXGetCurrentContext to fail.  That theory seems to fit the
> facts better than anything else that's been suggested - but it's certainly
> not proven.
> 
> The scientific method says that the next thing to do is a controlled experiment
> to test predictions made by this theory.  But since I run SuSE and have only an
> nVidia graphics card, I don't see the problem, I can't easily/cheaply do that.
> 
> Since this is plainly not a problem with anything I've written, it's really
> not my problem to solve.  The issue belongs (IMHO) in the Mesa mailing list...

I agree with this and will forward my findings to them.
The problem seems to me to be in 'glXGetCurrentContext'

> however, I'm subscribed to that list and so far I don't recollect anyone
> complaining there.
> 
> In the realm of OpenSource software, if you don't tell the right person
> the right problem, it won't ever get fixed.  (Although it may just "go away"
> of it's own accord - as I suspect this will).
> 
> So - that was before seeing your email.
> 
> Now we see another RedHat 7 derivitive with the problem - but NOT with
> the 2.96/2.97 compiler.  That's interesting - and probably deflates my
> "broken compiler" theory...although not entirely since most non-RH x86
> users are on 2.95.2 and you are using 2.95.3 - and on a different CPU
> architecture.
> 
> What other things might be common between these broken systems?

I have taken a peek at the source for 'glXGetCurrentContext' and its
full of #ifdefs and on my platform appears to return NULL regardless.
The differences between implementations is probably local #defines
and config files including such things as DIRECT/INDIRECT rendering,
PTHREADS, and complicated deferred execution and mutex code between
X and GL. I'm going to wade through the code but its ugly.

> 
> What Xfree version are you all running?  Is anyone else running that
> version with the same version of Mesa and NOT seeing the problem?
> 

Mine is XFree86 4.0.2-6e built by YDL (terrasoft)

> > I compiled the plib_examples and get the same message from
> > examples/src/ssg/tux/tux_example and examples/src/ssg/viewer/viewer
> > Further investigation indicates that *after* calling 'glutCreateWindow'
> > there is no valid OpenGL context according to 'ssgInit'. How does
> > ssgInit
> > determine this? It calls 'glXGetCurrentContext' which returns NULL even
> > though 'glutCreateWindow' thinks it has created a valid context..
> > Thus the root of the problem is an incompatibility between:
> > 'glutCreateWindow' and 'glXGetCurrentContext'.
> 
> Actually, you can get the same bug using 'freeglut' and in PPE which
> doesn't use GLUT at all.  Hence it's not glutCreateWindow itself
> but whatever underlying X11 call is common to FLTK and GLUT/freeglut...
> XCreateWindow being the most likely candidate.

I'll check that - maybe can get problem without GLUT - just within
GLX - that would narrow it down a bit.

> 
> > 'ssgInit' doesn't
> > have much to do with it except that it generates the error message.
> 
> Indeed.  Which is why this is the wrong mailing list to report the
> problem to.

True - but there was a lot of discussion and (unfortunately) you are
going to get the calls because you generate the message :-)

> 
> > It is easier to debug a small program with these two calls than
> > to begin with FlightGear...
> 
> Yes - something like that would be useful.  Unfortunately, I can't
> write that program because I don't have a system that exhibits the
> bug.

I can. see attached

> 
> > Now my question, to which groups should this information be directed?
> 
> I suggest the Mesa mailing list.  You can find info on how to subscribe
> on www.mesa3d.org.  I'd greatly appreciate it if you would first write
> that 10 line test program so that the problem can be expressed in a
> manner that won't result in it being immediately reflected back onto
> this list as a PLIB problem.

I couldn't get it into 10 lines but its under 60. No PLIB
code either.

> 
> > Platform Macintosh G4 Cube and YellowDogLinux 2.0
> > OpenGL 1.2, Mesa 3.4 and GLUT 3.7
> 
> What 3D hardware do you have?

apparently "ATI Rage 128 Pro PF (AGP)"

> 
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net       http://tuxaqfh.sf.net
>            http://prettypoly.sf.net http://tuxkart.sf.net
>            http://freeglut.sf.net   http://toobular.sf.net

=============================cut
here=======================================
/* Copyright (c) 2001 Stephen Lewis */
/* modified 31-Aug-2001 */
/*

  Illustrates a problem with OpenGL context
  comments please to 'le...@na...'

gcc -O2 -Wall   -c -o main.o main.c
gcc -O2 -Wall  -lglut -lGL -lGLU -lm  -o main main.o
./main

*/

#include <stdlib.h>
#include <stdio.h>
#include <GL/glut.h>
#include <GL/glx.h>

void reshape ( int w, int h )
{
  glViewport ( 0, 0, w, h ) ;
}

void keyboard ( unsigned char key, int x, int y)
{
  exit ( 0 ) ; /* exit for any key */
}

void redraw ()
{
  glClearColor( 1.0, 0.5, 0.0, 0.0 );
  glClear  ( GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT ) ;
  glutSwapBuffers ();
}

int main(int argc, char **argv) {
  int   fake_argc = 1 ;
  char *fake_argv[3] ;
  fake_argv[0] = "SL_Test" ;
  fake_argv[1] = "SL Example Program." ;
  fake_argv[2] = NULL ;

  /*
    Initialise GLUT
  */

  glutInitWindowPosition (10, 10);
  glutInitWindowSize     ( 640, 480 ) ;
  glutInit               ( &fake_argc, fake_argv ) ;
  glutInitDisplayMode    ( GLUT_RGB | GLUT_DOUBLE | GLUT_DEPTH ) ;
  glutCreateWindow       ( fake_argv[1] ) ;
/* without next two callbacks - get fatal error from glutMainLoop */
  glutDisplayFunc        ( redraw   ) ;
  glutReshapeFunc        ( reshape  ) ;

  glutKeyboardFunc       ( keyboard ) ;

  /*
    Check the context
  */

  if (glXGetCurrentContext() == NULL) {
        printf("SL_Test: glXGetCurrentContext returns NULL\n");
        printf("SL_Test: This is incorrect\n");
  } else {
        printf("SL_Test: glXGetCurrentContext returns SOMETHING\n");
        printf("SL_Test: This is (presumably) the correct context\n");
  };

  glutMainLoop ();

  return 0;
}
=============================cut
here=======================================

[Plib-users] Mailing list SNAFU.

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

I've just noticed that someone/something at SourceForge has changed all
the PLIB mailing list setups such that hitting 'Reply' to a message from
the list only replies to the author of the original message and not to
the list itself.  This was not the case a week or so ago.

I *hate* lists that work that way - so I've just gone in and changed them
all back again.  However, you may wish to check back on any replies you've
made recently and repost them to the list.

----------------------------- Steve Baker -------------------------------
Mail : <sjb...@ai...>   WorkMail: <sj...@li...>
URLs : http://web2.airmail.net/sjbaker1
       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] Re: flightgear problem

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

Stephen Lewis wrote:
> 
> Gentlemen,
> I have joined this list because I have the "flightgear" problem.
> I have just read a weeks worth of discussion concerning the
> "ssgInit called without a valid OpenGL context". I tried to compile
> FlighGear 0.7.8 on a PowerPC running YellowDogLinux 2.0.
> Although based on RH 7 there is no MMX and the compiler is 2.95.3

That's interesting new information.  Which OpenGL version do you have?

> There has been much speculation and not much science in this discussion.

Well, there has been science to the extent that I personally can provide
science.  The facts I have to date are:

  * glXGetCurrentContext is returning NULL
  * ...which is *SUPPOSED* to mean that there isn't a
    valid OpenGL rendering context.
  * But we demonstrably *DO* have a rendering context at that
    point because we can comment out the glXGetCurrentContext and
    the program runs correctly.
  * The exact same sequence of instructions when run on other OpenGL
    implementations (eg nVidia's) and/or other windowing systems (eg Windoze)
    and/or different C++ compilers (eg 2.95.2) *DOES* result in a valid
    result from glXGetCurrentContext.
  * This same problem shows up in other OpenGL programs that test
    glXGetCurrentContext...not just PLIB programs.
  * Up until today, every instance of the problem had been on
    systems running Mesa under RH 7.x or Mandrake 8.x.  I've never
    heard of such a system that worked - or of any other system that
    didn't work.

So, what are we to deduce from these facts?

I'm inclined to believe therefore that this is some kind of an underlying
bug in the windowing system or OpenGL implementation...probably the latter...
caused by *something* unique to RH implementations (and other systems that
share something with it).

I'm currently working under the presumption that the "known-to-be-dubious"
C++ compiler (GCC 2.96/2.97) is mis-compiling Mesa in some subtle manner
that causes glXGetCurrentContext to fail.  That theory seems to fit the
facts better than anything else that's been suggested - but it's certainly
not proven.

The scientific method says that the next thing to do is a controlled experiment
to test predictions made by this theory.  But since I run SuSE and have only an
nVidia graphics card, I don't see the problem, I can't easily/cheaply do that.

Since this is plainly not a problem with anything I've written, it's really
not my problem to solve.  The issue belongs (IMHO) in the Mesa mailing list...
however, I'm subscribed to that list and so far I don't recollect anyone
complaining there.

In the realm of OpenSource software, if you don't tell the right person
the right problem, it won't ever get fixed.  (Although it may just "go away"
of it's own accord - as I suspect this will).

So - that was before seeing your email.

Now we see another RedHat 7 derivitive with the problem - but NOT with
the 2.96/2.97 compiler.  That's interesting - and probably deflates my
"broken compiler" theory...although not entirely since most non-RH x86
users are on 2.95.2 and you are using 2.95.3 - and on a different CPU
architecture.

What other things might be common between these broken systems?

What Xfree version are you all running?  Is anyone else running that
version with the same version of Mesa and NOT seeing the problem?

> I compiled the plib_examples and get the same message from
> examples/src/ssg/tux/tux_example and examples/src/ssg/viewer/viewer
> Further investigation indicates that *after* calling 'glutCreateWindow'
> there is no valid OpenGL context according to 'ssgInit'. How does
> ssgInit
> determine this? It calls 'glXGetCurrentContext' which returns NULL even
> though 'glutCreateWindow' thinks it has created a valid context..
> Thus the root of the problem is an incompatibility between:
> 'glutCreateWindow' and 'glXGetCurrentContext'.

Actually, you can get the same bug using 'freeglut' and in PPE which
doesn't use GLUT at all.  Hence it's not glutCreateWindow itself
but whatever underlying X11 call is common to FLTK and GLUT/freeglut...
XCreateWindow being the most likely candidate.

> 'ssgInit' doesn't
> have much to do with it except that it generates the error message.

Indeed.  Which is why this is the wrong mailing list to report the
problem to.

> It is easier to debug a small program with these two calls than
> to begin with FlightGear...

Yes - something like that would be useful.  Unfortunately, I can't
write that program because I don't have a system that exhibits the
bug.

> Now my question, to which groups should this information be directed?

I suggest the Mesa mailing list.  You can find info on how to subscribe
on www.mesa3d.org.  I'd greatly appreciate it if you would first write
that 10 line test program so that the problem can be expressed in a
manner that won't result in it being immediately reflected back onto
this list as a PLIB problem.

> Platform Macintosh G4 Cube and YellowDogLinux 2.0
> OpenGL 1.2, Mesa 3.4 and GLUT 3.7

What 3D hardware do you have?
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

[Plib-users] Re: flightgear problem

[Stephen L. <le...@na...>]

Gentlemen,
I have joined this list because I have the "flightgear" problem.
I have just read a weeks worth of discussion concerning the
"ssgInit called without a valid OpenGL context". I tried to compile
FlighGear 0.7.8 on a PowerPC running YellowDogLinux 2.0.
Although based on RH 7 there is no MMX and the compiler is 2.95.3
There has been much speculation and not much science in this discussion.
I compiled the plib_examples and get the same message from
examples/src/ssg/tux/tux_example and examples/src/ssg/viewer/viewer
Further investigation indicates that *after* calling 'glutCreateWindow'
there is no valid OpenGL context according to 'ssgInit'. How does
ssgInit
determine this? It calls 'glXGetCurrentContext' which returns NULL even
though 'glutCreateWindow' thinks it has created a valid context..
Thus the root of the problem is an incompatibility between:
'glutCreateWindow' and 'glXGetCurrentContext'. 'ssgInit' doesn't
have much to do with it except that it generates the error message.
It is easier to debug a small program with these two calls than
to begin with FlightGear...
Now my question, to which groups should this information be directed?
Thsnks for interest,
Stephen Lewis
Platform Macintosh G4 Cube and YellowDogLinux 2.0
OpenGL 1.2, Mesa 3.4 and GLUT 3.7

Re: ..gcc-3.x.y & RH7.z, was: [Plib-users] Fwd: Re: flightgear problem

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

"Trond Eivind Glomsrød" wrote:
> 
> Arnt Karlsen <ar...@c2...> writes:
> 
> > On Sun, 26 Aug 2001 00:10:59 -0500,
> > Steve Baker <sjb...@ai...>
> > wrote in <3B8...@ai...>:
> >
> > > pieter bonne wrote:
> > > >

..[...bg & defense snipped...]

> > ..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
> > Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?
> 
> This isn't a software proplem, it's as people problem. Lack of
> knowledge can be an inflammatory thing.
> 
> 2.96RH will of course remain the standard compiler through the 7.x
> series. For the next major series, we intend to move to gcc 3 if it's
> mature enough at the time (if not, it'll just be another 7.x,
> probably).

..agreed.  Ok.  Meanwhile, just how do I get Flightgear running?


On Mon, 27 Aug 2001 03:04:09 -0500, Steve Baker <sjb...@ai...>
wrote in <3B8...@ai...>:

> Arnt Karlsen wrote:
> >
> > ..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
> > Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?
> 
> Well, it's possible that there will be problems with GCC 3.0 - and I've
> had mixed reports (at least one person said that they had weird problems
> and two people said that it "just worked" except for a couple of places
> where I had #include'd the wrong header files for some standard functions
> and had been "getting away with it".  eg <sys/time.h> and <time.h>)
> 
> So whether 3.0 will be good or not - I don't know.  I generally avoid
> "x.0.0" releases - I don't have the energy to chase compiler problems
> and I'd rather a few hundred thousand other people found the hard problems
> before I give them a whirl.
> 
> However, that misses the point.  2.96/7 were never actually released
> by the GCC team - so it's unreasonable to email them saying "you screwed
> up Mesa - please fix it"...however, if 3.0 screws up Mesa then it's
> perfectly reasonable (even desirable) to enter into a dialog with the
> Mesa team and the GCC team to try to figure out what's going on.
> 
> So if you have problems with 2.96/7, you shouldn't complain to PLIB
> or Mesa or even the GCC team because the fault doesn't lie with any
> of those groups.  That only leaves RedHat's customer support.


..who I guess needs help identifying the problems.

 
> ----------------------------- Steve Baker -------------------------------
> HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
> HomePage : http://web2.airmail.net/sjbaker1
> Projects : http://plib.sf.net       http://tuxaqfh.sf.net
>            http://prettypoly.sf.net http://tuxkart.sf.net
>            http://freeglut.sf.net   http://toobular.sf.net
> 
> _______________________________________________
> plib-users mailing list
> pli...@li...
> http://lists.sourceforge.net/lists/listinfo/plib-users
> 

..ps: TEG, jeg fwd'er svaret ditt til plib-lista, du glemte den.

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

[Fwd: ..gcc-3.x.y & RH7.z, was: [Plib-users] Fwd: Re: flightgear problem]

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

"Trond Eivind Glomsrød" wrote:
> 
> Arnt Karlsen <ar...@c2...> writes:
> 
> > On Sun, 26 Aug 2001 00:10:59 -0500,
> > Steve Baker <sjb...@ai...>
> > wrote in <3B8...@ai...>:
> >
> > > pieter bonne wrote:
> > > >
> > > > greetings,
> > > >
> > > > First of all, thanks for such a lengthy response.. It's all quite clear to me
> > > > now.. So in a nutshell, the problem I am experiencing is due to a bug in that
> > > > version of mesa.. I can't really comprehend how such an important call can
> > > > get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to
> > > > flightgear (using plib)..
> > >
> > > Well, there are two reason why that may have sneaked through
> > >
> > >   * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power users'
> > >     have abandoned those two distro's following the gcc debacle.
> 
> "Informed" users such as yourself? Happily, there is no such trend.
> 
> > >     Hence none of the Mesa developers are likely to have tested
> > >     under RedHat to any great degree.
> 
> I'd like to see you substantiate that claim... but then, I'm probably
> expecting too much. Here you have a great, flaming article - facts are
> bothersome.
> 
> > > > I don't think the fact of the 2.96 compiler has anything to do with all
> > > > this.. All packages I installed are compiled by this compiler!
> > >
> > > Yes - but the problem only shows up on RedHat/Mandrake and the only thing that's
> > > really obviously in common that could possibly have an effect is the C compiler.
> 
> If this is a Mesa issue, I'd rather suspect that it's caused by our
> Mesa library - it's changed a bit, in order to provide GLX for cards
> still using XFree 3.3.x servers.
> 
> Of course, this doesn't rule out a problem in the code or compiler (of
> these, a problem in the code is far more likely).
> 
> > > You *are* aware of the 2.96/2.97 compiler "issues" - right?   The deal is (in
> > > a nutshell) that the last released version of the GCC product was 2.95 - they
> > > were working towards the major new 3.0.0 release but didn't get there in time
> > > to make the RedHat 7.0 release date.  What RedHat did was to grab the "weekly
> > > snapshot" of the pre-3.0 CVS load and release that into the world.
> 
> Not true. We grabbed a snapshot, and then QAed it, fixed it and
> worked hard on it.
> 
> The reason? 2.95.x was unacceptably buggy - it couldn't even compile
> glibc (you'll note that this is still the case for gcc 3). The
> performance on non-IA32 systems was also very bad. Compliance to C++
> standards was also severely lacking. And there was no support for IA64
> at all. When a release was obviously sorely needed they chose do
> everything at once, resulting in a very late and not very good gcc
> 
> The result? We've had the best compiler around for a year, and when we
> switch we'll get a somewhat mature gcc 3 (the "final" ABI wasn't as
> final as it should have been on all platforms either). 2.96RH is
> arguably still better than gcc 3 in many areas (less bugs), while
> being better than 2.95.x and not as good as gcc 3.0 in other areas
> (like C++ compliance).
> 
> > > The GCC team objected - RedHat didn't listen.
> 
> They did not complain before shipping (and remember, we had a public
> beta). Our internal compiler group were aware of the plans, and had
> recommended it. This includes members of the gcc steering committee
> (not surprising, as Red Hat includes  former Cygnus and thus is a huge
> contributor to gcc). There was a commonications misunderstanding to
> the rest of the gcc committee, and we should have marked it more
> clearly as a "Red Hat" release. Politicswise it could have been
> handled better, technically it was the best choice  .
> 
> I've even talked to Mark Mitchell myself, and his issue was that we
> didn't brand it properly - the initial release didn't refer to
> bugzilla if anything went wrong, to give one example.
> 
> > > The Kernel team said that the kernel wouldn't compile with 2.96 so
> > > RedHat also released the 2.95 compiler under the name 'kgcc'
> 
> There was a bug in the 2.2.16 kernel  shipped with RHL 7, and the
> kernel is very compilerdependent (including handcoded knowledge of how
> the compiler interacts with assembly, how structs are laid out) etc -
> thus, using egcs 1.1.2 (we've never shipped 2.95.x) was the safest
> choice. An absense of problems doesn't mean there aren't any others
> will run into.
> 
> > > - which you'll have on your disk.  However since 2.95 and 2.96
> > > can't share the same libraries (and 2.96 can't share with 3.0 either), you can't
> > > just recompile things like PLIB and Mesa using kgcc.
> 
> Mesa is a C library, you can mix and match whatever compilers you
> want.
> 
> > > So basically, they TOTALLY screwed up RH 7.0.
> 
> No, we did not. It's a good release, with a good compiler. Better than
> any other alternatives at the time
> 
> > > Everyone complained bitterly but *AMAZINGLY* they didn't go back
> > > to 2.95 in RH 7.1
> 
> Of course not. We need to preserve binary compatiblity for C++. 2.95.x
> wouldn't have been compatible with anything we've ever shipped. No gcc
> compilers haver ever been binary compatible with other version
> wrt. C++ (not counting patchlevels - 2.7.2 and 2.7.3 are compatible,
> 2.7.x and 2.8.x are not)
> 
> > > - so the GCC team (who get most of their funding from RedHat) gave
> > > this "bogus" version the number 2.97..
> 
> No, they didn't. They've never released it. 2.96RH is the result of
> gcc being open source - if something is broken, you can fix it
> yourself.  They increased the version number from 2.96 to 2.97 in CVS
> to avoid confusion.
> 
> > > It is unsuprising under the circumstances that none of the serious developers
> > > out there are particularly inclined to try to diagnose problems that only
> > > affect RedHat 7.x or Mandrake 8.x under these circumstances.
> 
> I've not seen any take it that way, considering the fact that 2.96RH
> is the most stable compiler out there now.
> 
> > > Personally, I think RedHat is becoming like another Microsoft - deliberately
> > > using incompatible versions to lock people into their software distro - hoping
> > > that their market share is large enough to lock people in.
> 
> The software is GPL. Anyone can ship it (as you've seen, Mandrake has
> done that). Standards for binary compatibility explicitly say "don't
> use C++ dynamic libraries". We've no intention of locking people
> in. Offering the best technology around is a much better way (even if
> it takes extra work, like gcc), and this is what you'll find in Red
> Hat Linux.
> 
> > ..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
> > Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?
> 
> This isn't a software proplem, it's as people problem. Lack of
> knowledge can be an inflammatory thing.
> 
> 2.96RH will of course remain the standard compiler through the 7.x
> series. For the next major series, we intend to move to gcc 3 if it's
> mature enough at the time (if not, it'll just be another 7.x,
> probably).
> 
> --
> Systems Engineer - OS Engineering; Red Hat, Inc.
> ************************************************
> Want to help translate for your language?
> http://sources.redhat.com/rhl/i18n/

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [Plib-users] Fwd: Re: flightgear problem

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

pieter bonne wrote:
> 
> On Sunday 26 August 2001 07:10, you wrote:
> >   * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power
> > users' have abandoned those two distro's following the gcc debacle.  Hence
> > none of the Mesa developers are likely to have tested under RedHat to any
> > great degree.
> How can this be a compiler issue? I thought this was a programming bug? It
> however remains curious why redhat and mandrake seem affected anyway.. but I
> see no reason why it would be compiler related.. It's just a flawed function
> somewhere.. not?

If the 2.96/7 compilers are correctly translating the same source code into
valid assembler, it's hard to see how only RedHat 7.0, 7.1 and Mandrake 8
would exhibit the problem.  Is it just a coincidence that the main thing
these have in common that no other distro has is that compiler revision?

Maybe not - but it's hard to find another explanation.

> > You *are* aware of the 2.96/2.97 compiler "issues" - right?
> Yep, I am.. There are a lot of tools that even require 2.95 or 3 even to
> allow you to build.. (mainly video software, because pentium-mmx manipulation
> seems really messed up)

OK - I didn't know that MMX was a problem with those compiler versions - but
I can tell you for sure that Mesa *does* use MMX.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: ..gcc-3.x.y & RH7.z, was: [Plib-users] Fwd: Re: flightgear problem

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

Arnt Karlsen wrote:
>
> ..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
> Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?

Well, it's possible that there will be problems with GCC 3.0 - and I've
had mixed reports (at least one person said that they had weird problems
and two people said that it "just worked" except for a couple of places
where I had #include'd the wrong header files for some standard functions
and had been "getting away with it".  eg <sys/time.h> and <time.h>)

So whether 3.0 will be good or not - I don't know.  I generally avoid
"x.0.0" releases - I don't have the energy to chase compiler problems
and I'd rather a few hundred thousand other people found the hard problems
before I give them a whirl.

However, that misses the point.  2.96/7 were never actually released
by the GCC team - so it's unreasonable to email them saying "you screwed
up Mesa - please fix it"...however, if 3.0 screws up Mesa then it's
perfectly reasonable (even desirable) to enter into a dialog with the
Mesa team and the GCC team to try to figure out what's going on.

So if you have problems with 2.96/7, you shouldn't complain to PLIB
or Mesa or even the GCC team because the fault doesn't lie with any
of those groups.  That only leaves RedHat's customer support.
 
----------------------------- Steve Baker -------------------------------
HomeMail : <sjb...@ai...>   WorkMail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sf.net       http://tuxaqfh.sf.net
           http://prettypoly.sf.net http://tuxkart.sf.net
           http://freeglut.sf.net   http://toobular.sf.net

Re: [Plib-users] Fwd: Re: flightgear problem

[pieter b. <xa...@gm...>]

On Sunday 26 August 2001 07:10, you wrote:
>   * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power
> users' have abandoned those two distro's following the gcc debacle.  Hence
> none of the Mesa developers are likely to have tested under RedHat to any
> great degree.
How can this be a compiler issue? I thought this was a programming bug? It 
however remains curious why redhat and mandrake seem affected anyway.. but I 
see no reason why it would be compiler related.. It's just a flawed function 
somewhere.. not?

> You *are* aware of the 2.96/2.97 compiler "issues" - right? 
Yep, I am.. There are a lot of tools that even require 2.95 or 3 even to 
allow you to build.. (mainly video software, because pentium-mmx manipulation 
seems really messed up) 

kind regards,
-xas-

--
Felson's Law:
        To steal ideas from one person is plagiarism; to steal from
        many is research.

..gcc-3.x.y & RH7.z, was: [Plib-users] Fwd: Re: flightgear problem

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

On Sun, 26 Aug 2001 00:10:59 -0500, 
Steve Baker <sjb...@ai...> 
wrote in <3B8...@ai...>:

> pieter bonne wrote:
> > 
> > greetings,
> > 
> > First of all, thanks for such a lengthy response.. It's all quite clear to me
> > now.. So in a nutshell, the problem I am experiencing is due to a bug in that
> > version of mesa.. I can't really comprehend how such an important call can
> > get bugged, but anyway.. Due to that bug, the context doesn't "seem" ready to
> > flightgear (using plib)..
> 
> Well, there are two reason why that may have sneaked through
> 
>   * It only seems to affect RedHat 7.x and Mandrake 8 and most 'power users'
>     have abandoned those two distro's following the gcc debacle.  Hence none
>     of the Mesa developers are likely to have tested under RedHat to any great
>     degree.
> 
>   * As you have noticed, many other programs (Quake for instance) do not bother
>     to check that the current rendering context is valid.  The only reason that
>     PLIB really needs to do it is that it's used by a hundred applications and
>     I have no control over whether one or other of them is breaking the rules.
>     Hence I need to protect the library from false allegations by doing that test.
>     Quake has no need to do that - they know that they open the OpenGL window
>     and that it opened without error and hence there *MUST* be a valid rendering
>     context.   PLIB cannot be certain that this has happened if that application's
>     author screwed up.
> 
> > I don't think the fact of the 2.96 compiler has anything to do with all
> > this.. All packages I installed are compiled by this compiler!
> 
> Yes - but the problem only shows up on RedHat/Mandrake and the only thing that's
> really obviously in common that could possibly have an effect is the C compiler.
> 
> You *are* aware of the 2.96/2.97 compiler "issues" - right?   The deal is (in
> a nutshell) that the last released version of the GCC product was 2.95 - they
> were working towards the major new 3.0.0 release but didn't get there in time
> to make the RedHat 7.0 release date.  What RedHat did was to grab the "weekly
> snapshot" of the pre-3.0 CVS load and release that into the world.  The GCC
> team objected - RedHat didn't listen.  The Kernel team said that the kernel
> wouldn't compile with 2.96 so RedHat also released the 2.95 compiler under
> the name 'kgcc' - which you'll have on your disk.  However since 2.95 and 2.96
> can't share the same libraries (and 2.96 can't share with 3.0 either), you can't
> just recompile things like PLIB and Mesa using kgcc.
> 
> So basically, they TOTALLY screwed up RH 7.0.  Everyone complained bitterly
> but *AMAZINGLY* they didn't go back to 2.95 in RH 7.1 - so the GCC team
> (who get most of their funding from RedHat) gave this "bogus" version the
> number 2.97...but it's still just as broken.  Mandrake (as usual) blindly
> followed RedHat's lead - so Mandrake 8.0 is also "broken".
> 
> It is unsuprising under the circumstances that none of the serious developers
> out there are particularly inclined to try to diagnose problems that only
> affect RedHat 7.x or Mandrake 8.x under these circumstances.
> 
> Personally, I think RedHat is becoming like another Microsoft - deliberately
> using incompatible versions to lock people into their software distro - hoping
> that their market share is large enough to lock people in.
> 
> They shouldn't be allowed to get away with this - so, I recommend that you
> keep RedHat's support lines as busy as possible with these complaints - either
> that or switch to Debian, SuSE, Slackware or one of the smaller distro's.
> 

..how about Red Hat 7.z/Rawhide and gcc 3.x.y?   TEG?
Will gcc version 3 onwards fix the Red Hat 7.z "gcc-2.96/7" problem?

-- 
..med vennlig hilsen = with Kind Regards from Arnt... ;-)

  Scenarios always come in sets of three: 
  best case, worst case, and just in case.

Re: [Plib-users] Fwd: Re: flightgear problem

[pieter b. <xa...@gm...>]

On Saturday 25 August 2001 23:40, you wrote:
> Suse for example messed something up with X binary/lib versions which
> caused problems with SDL. Something I had to find out the hard way when
> trying to demonstrate a SDL application to a customer on one of their
> computers which was using this version of Suse. Not one of my pleasant
> memories...
Redhat didn't just mess up, they deliberately messed up.. there's quite a 
difference in that.. They have done quite some good things indeed, but I just 
hope they will keep the open-source spirit alive, and won't let the 
commercial aspect become more important. They seem to have been trying to 
grab market share quite deliberately with this gcc-release everyone else 
surely wouldn't have released in their distro.. and therefore creating binary 
incompatabilities and betraying the community in some sence..
> Redhat has done quite a lot for Linux imho and they are free to choose any
> Compiler version they like and no matter what teir decision is, I dont
> think it justifies an insult like "becoming another microsoft", which is
> probably the worst insult possible in the free software world. (If anybody
> can come up with a better one , tell us :)
Red(mond)Hat? :^)

-xas-

--
I never met a piece of chocolate I didn't like.