Thread: [Plib-users] Library Initialization
Brought to you by:
sjbaker
Menu
▾
▴
plib-users
|
From: Elad L. <el...@el...> - 2000-10-08 06:28:01
|
I have tried a couple of programmes based on plib, and encountered the same result. The plib libraries will not initialize, claiming a GL context was not created. I have checked the source of these applications (FlightGear and some Tux game), and seen that glutInit is called, so it should have worked. Any suggestions? I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with a 3dfx Voodoo3 3000. Elad |
|
From: Norman V. <nh...@ca...> - 2000-10-08 12:31:57
|
Elad Lahav writes: > >I have tried a couple of programmes based on plib, and encountered the same >result. The plib libraries will not initialize, claiming a GL context was >not created. I have checked the source of these applications (FlightGear and >some Tux game), and seen that glutInit is called, so it should have worked. >Any suggestions? >I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with >a 3dfx Voodoo3 3000. Sounds like this might be a compiler issue. RedHat 7.0 is shipping with a gcc that produces non-compatable c++ object files. see http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html FWIW My guess is that if you make sure all files including linked libs are compiled on your machine things should work. ie no rpm's unless compiled specifically for RedHat 7.0 < disclaimer > I have never even booted Linux, but I do have LOTS of experience with incompatable object file formats ( Thanks M$oft ) :-( </> Good Luck Norman |
|
From: Steve B. <sjb...@ai...> - 2000-10-08 15:34:43
|
Norman Vine wrote: > >I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with > >a 3dfx Voodoo3 3000. > > Sounds like this might be a compiler issue. > RedHat 7.0 is shipping with a gcc that produces > non-compatable c++ object files. > see > http://gcc.gnu.org/ml/gcc-announce/2000/msg00003.html > > FWIW > My guess is that if you make sure all files including linked libs > are compiled on your machine things should work. Oooh! Yes - I'd forgotten about *that*. This is a *very* good excuse! We can blame all RH7 problems on this one! SuSE Linux Roolz! (etc) The most ironic thing about this horrible fiasco is that most gcc development is done by Cygnus people who are owned by RedHat!! I'm really upset that RedHat would do such an incredibly STOOPID thing. I think the gcc people are being most restrained about the whole thing. (If you didn't hear, RedHat took an unreleased CVS copy of gcc and released it on RH7's CD collection. It's quite the most irresponsible thing they've done for a LONG time!) -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
|
From: Elad L. <el...@el...> - 2000-10-10 06:01:40
|
OK, I have tried to exclude as many reasons as possible for this failure, and this is what I got: 1. Reinstalled RH 7, with the original kernel and libraries, and still got the same GL context issue 2. Compiled other, non-plib, GL-dependant programmes. They seemed to work fine. 3. When trying FlightGear, I have compiled all libraries and programmes (plib, SimGear and FlightGear), on the same machine, with the same compiler, at the same time (so you can't even blame it on weather changes...;-) Anything else? Elad By the way, thanks for the quick responds... |
|
From: Norman V. <nh...@ca...> - 2000-10-10 12:28:48
|
Elad Lahav writes:
>
>OK, I have tried to exclude as many reasons as possible for
>this failure,
>and this is what I got:
>1. Reinstalled RH 7, with the original kernel and libraries,
>and still got the same GL context issue
>2. Compiled other, non-plib, GL-dependant programmes. They
>seemed to work fine.
>3. When trying FlightGear, I have compiled all libraries and programmes
>(plib, SimGear and FlightGear), on the same machine, with the
>same compiler,
>at the same time (so you can't even blame it on weather changes...;-)
>Anything else?
Hmm...
What versions of the libraries are you using ??
Did RedHat include these or did you download them ?
Is there a
/ usr / local / include / plib
that is hiding
/ usr / include / plib
What does running this produce
#include <stdio.h>
#include <plib/ssg.h>
iny main(int argc char **argv) {
printf("Plib Version %s\n", ssgGetVersion());
}
Cheers
Norman
|
|
From: tjones <tj...@is...> - 2000-10-10 22:37:46
|
Try getting plib from cvs, and get the examples as well. Let me know if the examples are not working either. Also do you have glut installed. Also if you want you can mail me directly and I can try to help you off this list. Later Ben ----- Original Message ----- From: Elad Lahav <el...@el...> To: <pli...@li...> Sent: Tuesday, October 10, 2000 2:58 AM Subject: RE: [Plib-users] Library Initialization > OK, I have tried to exclude as many reasons as possible for this failure, > and this is what I got: > 1. Reinstalled RH 7, with the original kernel and libraries, and still got > the same GL context issue > 2. Compiled other, non-plib, GL-dependant programmes. They seemed to work > fine. > 3. When trying FlightGear, I have compiled all libraries and programmes > (plib, SimGear and FlightGear), on the same machine, with the same compiler, > at the same time (so you can't even blame it on weather changes...;-) > Anything else? > > Elad > > By the way, thanks for the quick responds... > > > _______________________________________________ > plib-users mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-users > > |
|
From: Steve B. <sjb...@ai...> - 2000-10-11 04:12:07
|
Elad Lahav wrote:
>
> OK, I have tried to exclude as many reasons as possible for this failure,
> and this is what I got:
> 1. Reinstalled RH 7,
*BZZT*BZZT* WARNING! WARNING!
You might want to downgrade your gcc to something that works. RedHat
are coming in for a lot of flak over their decision to ship a relatively
poorly tested beta version.
> with the original kernel and libraries, and still got
> the same GL context issue...
Well - I'm rather unconvinced - I don't think this is a PLIB problem.
> 2. Compiled other, non-plib, GL-dependant programmes. They seemed to work
> fine.
Well, that's interesting - but I *still* don't think it's a PLIB problem.
The deal is that you really havn't run much PLIB code by this stage:
The rule is that the first SSG function to be called MUST be ssgInit - and
ssgInit must not be called until there is a valid OpenGL rendering context.
The very first line of that function is a call to glIsValidContext whose
very first line is to ask X if there is a valid rendering context.
Immediately upon return, you are getting that error message saying
that there isn't a valid context.
So, if FGFS has a valid rendering context in the line immediately before
the very first ever call to a PLIB function (well, a PUI, FNT or SSG function
at least) - then you could insert a glXGetCurrentContext in the line just
before ssgInit is called and it would return some non-NULL value.
Then you are telling me that sometime in the next three lines, PLIB somehow
corrupts that context and then - testing it a second time - get's NULL back?
I don't believe that.
Ergo FGFS did not have a valid context before calling ssgInit - so it's
FGFS's fault. I can't see a flaw in that reasoning.
You may not previously have seen this message with earlier versions
of PLIB because we were not doing the check - now we are, we may have
uncovered a FGFS error of some kind....I don't know.
> 3. When trying FlightGear, I have compiled all libraries and programmes
> (plib, SimGear and FlightGear), on the same machine, with the same compiler,
> at the same time (so you can't even blame it on weather changes...;-)
> Anything else?
Well, I think you should hack into plib/src/ssg/ssg.cxx, see where it says 'glXGetCurrentContext'
in 'glIsValidContext' - print out the value that glXGetCurrentContext returns. Also stick
a printf inside 'ssgInit' so we know that it is truly what called glIsValidContext.
Now, put a check for glXGetCurrentContext into FGFS in the line before you call
ssgInit - and you'll know for sure.
Incidentally, a similar test for a valid OpenGL context is made in PUI's puInit
(which FGFS is presumably also calling)...and also in the FNT font loader.
*PRESUMABLY* those are being called after ssgInit - so we don't see them complain.
I *suspect* the RedHat C++ compiler - it's been implicated in several problems in
other projects this week. If I'd bought a copy of RH 7, I'd be demanding my money
back. They did a VERY irresponsible thing and use poor package maintainers are
suffering the consequences. That gets me somewhat upset. I can only imagine
what the GCC maintainers are going through.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Sam S. <sa...@sp...> - 2000-10-11 17:03:13
|
----- Original Message ----- From: "Steve Baker" <sjb...@ai...> To: <pli...@li...> Sent: Tuesday, October 10, 2000 5:10 PM Subject: Re: [Plib-users] Library Initialization > Elad Lahav wrote: > > > > OK, I have tried to exclude as many reasons as possible for this failure, > > and this is what I got: > > 1. Reinstalled RH 7, > > *BZZT*BZZT* WARNING! WARNING! > > You might want to downgrade your gcc to something that works. RedHat > are coming in for a lot of flak over their decision to ship a relatively > poorly tested beta version. No need. Type recompiling everything with kgcc instead of gcc. kgcc is the Linus blessed version for compiling kernals. alias gcc kgcc might do the trick Sam |
|
From: Steve B. <sjb...@ai...> - 2000-10-11 19:04:09
|
Sam Stickland wrote:
> > You might want to downgrade your gcc to something that works. RedHat
> > are coming in for a lot of flak over their decision to ship a relatively
> > poorly tested beta version.
>
> No need. Type recompiling everything with kgcc instead of gcc. kgcc is the
> Linus blessed version for compiling kernals.
I havn't heard of that. It's not installed on SuSE Linux.
> alias gcc kgcc
>
> might do the trick
...and g++ ==> kg++ ?
I don't think an 'alias' will work BTW, the Makefile system probably uses
bash or something.
You'd probably have to rename the original gcc/g++ to something else and
symlink to them to kgcc or whatever.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Sam S. <sa...@sp...> - 2000-10-12 10:50:43
|
----- Original Message ----- From: "Steve Baker" <sjb...@ai...> To: <pli...@li...> Sent: Wednesday, October 11, 2000 12:04 PM Subject: Re: [Plib-users] Library Initialization > Sam Stickland wrote: > > > > You might want to downgrade your gcc to something that works. RedHat > > > are coming in for a lot of flak over their decision to ship a relatively > > > poorly tested beta version. > > > > No need. Type recompiling everything with kgcc instead of gcc. kgcc is the > > Linus blessed version for compiling kernals. > > I havn't heard of that. It's not installed on SuSE Linux. I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to the development release of gcc. > > alias gcc kgcc > > > > might do the trick > > ...and g++ ==> kg++ ? > > I don't think an 'alias' will work BTW, the Makefile system probably uses > bash or something. Yeah, I was thinking it might do that but I don't have to much experience with the way Unix shells handle their environments. I supposed you could add the aliases to.bashrc but to... > rename the original gcc/g++ to something else and > symlink to them to kgcc or whatever. ...is probably a better solution. Sam |
|
From: Steve B. <sjb...@ai...> - 2000-10-12 13:06:15
|
Sam Stickland wrote:
> > > > You might want to downgrade your gcc to something that works. RedHat
> > > > are coming in for a lot of flak over their decision to ship a
> relatively
> > > > poorly tested beta version.
> > >
> > > No need. Type recompiling everything with kgcc instead of gcc. kgcc is
> the
> > > Linus blessed version for compiling kernals.
> >
> > I havn't heard of that. It's not installed on SuSE Linux.
>
> I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to the
> development release of gcc.
So they were WELL AWARE of what they were doing - and the kernel guys complained
and they STILL WENT AHEAD! Yikes! This is much worse than I thought.
> > > alias gcc kgcc
> > >
> > > might do the trick
> >
> > ...and g++ ==> kg++ ?
> >
> > I don't think an 'alias' will work BTW, the Makefile system probably uses
> > bash or something.
>
> Yeah, I was thinking it might do that but I don't have to much experience
> with the way Unix shells handle their environments. I supposed you could
> add the aliases to.bashrc but to...
The way things are set up is to try to avoid user's own aliases creeping
into scripts and Makefiles and such. People like to do thing like:
alias ls ls -al
alias rm rm -i
alias test /home/steve/binaries/my_test_program
...which can play **HAVOC** with system scripts, configure scripts and
Makefiles!!
The system doesn't prevent you from doing things like that (because
UNIX likes to give you all the power it can) - but it is mildly
resistant to non-knowledgeable users tinkering.
> > rename the original gcc/g++ to something else and
> > symlink to them to kgcc or whatever.
>
> ...is probably a better solution.
Yes.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Sam S. <sa...@sp...> - 2000-10-12 15:47:08
|
> > I think it's only on RedHat 7.0 as a getout for Alan Cox's decision to the > > development release of gcc. > > So they were WELL AWARE of what they were doing - and the kernel guys complained > and they STILL WENT AHEAD! Yikes! This is much worse than I thought. Well we're getting wildly offtopic but here's Alan Cox's statement on the gcc inclusion: ---- From there, the argument ensued at full strength, with Linux kernel developer and Red Hat employee Alan Cox taking up the cause of Red Hat's decision to release Red Hat 7 with these packages. Cox's primary argument was that the inclusion of application like GCC 2.96 is innovative progress for users of Red Hat 7. "I want people to be prepared to ship new and innovative things," Cox wrote in the discussion, "If everyone complains about not shipping precise reference kernels, then all of a sudden for [kernel] 2.2 I become some anointed high power for approval for vendors--that is something I don't wish to be and which would be very, very bad for Linux. Do you really want a world where you cannot buy a distribution with 2.2 that has Reiserfs because Alan Cox refused to merge it with the mainstream?" ---- And later on ---- Cox's comments were echoed by Eric Troan, Red Hat's VP of Product Engineering in an online interview with Linux Today. "The questions which have arrived over the compiler is actually about the user-space compiler we ship, not the kernel compiler. The kernel compiler is essentially the same version we shipped in the last couple of Red Hat releases," Troan explained. "The user space is based on a snapshot version of gcc, which we have tested extensively inside of Red Hat. While no compiler is perfect, we've built tens of millions of lines of code and it works very well for us." ---- But most worrying is this statement: ---- Troan went on to outline Red Hat's position towards the accusations that Red Hat is attempting to depart from the Linux standard. "As for the compatibility issues, we do think binary compatibility between Linux distributions is very important. We do not ship kernels with extra APIs unless Linus Torvalds has accepted those new APIs into the development kernel trees. Likewise, we work hard to maintain full backwards compatibility," Troan said. "As the Linux Standard Base (LSB) group gets finalized, Red Hat will be fully compliant with it's recommendations, ensuring that LSB compatible applications will run on the widest varieties of Linux-compatible systems possible," Troan continued, "Fragmenting the Linux binary APIs will not help anyone. "Moving Linux forward is important, however. Doing that requires changes that can make it difficult to move applications from newer systems to older ones. This is inevitable, and every platform vendor has this type of problem (applications built for Windows 2000 apps do not work on Windows 98, for example, and Solaris applications do not run on SunOS). The LSB will provide a common denominator to allow application compatibility between releases while still providing a path for new features to be added to Linux distribution," Troan explained. ---- (He's wrong btw, apps compiled under Windows 2000 run just fine on 98 providing you don't make use of any API's that don't exist on 98). Sam > > > > alias gcc kgcc > > > > > > > > might do the trick > > > > > > ...and g++ ==> kg++ ? > > > > > > I don't think an 'alias' will work BTW, the Makefile system probably uses > > > bash or something. > > > > Yeah, I was thinking it might do that but I don't have to much experience > > with the way Unix shells handle their environments. I supposed you could > > add the aliases to.bashrc but to... > > The way things are set up is to try to avoid user's own aliases creeping > into scripts and Makefiles and such. People like to do thing like: > > alias ls ls -al > alias rm rm -i > alias test /home/steve/binaries/my_test_program > > ...which can play **HAVOC** with system scripts, configure scripts and > Makefiles!! > > The system doesn't prevent you from doing things like that (because > UNIX likes to give you all the power it can) - but it is mildly > resistant to non-knowledgeable users tinkering. > > > > rename the original gcc/g++ to something else and > > > symlink to them to kgcc or whatever. > > > > ...is probably a better solution. > > Yes. > > -- > Steve Baker HomeEmail: <sjb...@ai...> > WorkEmail: <sj...@li...> > HomePage : http://web2.airmail.net/sjbaker1 > Projects : http://plib.sourceforge.net > http://tuxaqfh.sourceforge.net > http://tuxkart.sourceforge.net > http://prettypoly.sourceforge.net > _______________________________________________ > plib-users mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-users > |
|
From: Steve B. <sjb...@ai...> - 2000-10-08 15:23:24
|
Elad Lahav wrote: > > I have tried a couple of programmes based on plib, and encountered the same > result. The plib libraries will not initialize, claiming a GL context was > not created. Well, it PLIB calls 'glXGetCurrentContext()' to test for a valid GL context. If that test fails then (somehow) you are not getting a valid context. > I have checked the source of these applications (FlightGear and > some Tux game), and seen that glutInit is called, so it should have worked. Well, only if glutInit managed to find a valid OpenGL context. Are you sure your OpenGL is correctly installed? Do (for example) the GLUT demo programs work? > I am using RedHat 7.0, kernel 2.4.0-test7, XFree86 4.0.1 with a 3dfx Voodoo3 > 3000. Well, I know that FlightGear and both Tux games that use PLIB (TuxKart, TuxAQFH do, TuxRacer doesn't) all work just fine with RedHat/Xfree4.0.1/Voodoo-3... that's a very well tested configuration....although the 2.4.0-test7 kernel is pretty suspicious. I think you should back up a little and try the GLUT/Mesa test programs. If those work, pick one of them and add a call to glXGetCurrentContext just after glutInit and check that it returns a non-NULL result. If all that works as expected then it's a PLIB problem - so come back to this list and we'll see what's going on. If those tests fail - then it's not a problem with either of the games or PLIB and you'll need to take it up with the Mesa team. (www.mesa3d.org) So, either it's the Kernel (I doubt it) or your Mesa installation (with all that DRI stuff, it can get tricky). -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X