Thread: [Plib-devel] Patches for FreeBSD
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Martin S. <Mar...@un...> - 2004-12-30 14:43:32
|
Hello, the FreeBSD folks have a small but fine collection of patches that enable PLIB to compile and work on FreeBSD. They offer their patches as part of the "ports collection": http://www.freebsd.org/cgi/cvsweb.cgi/ports/x11-toolkits/plib/files/ I made a copy available here: ftp://ftp.uni-duisburg.de/FlightGear/Devel/PLIBFreeBSD/ To my experience odds are good that these patches won't do any harm if committed to the official PLIB source tree. Would you please have a look ? Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Bert D. <dri...@pl...> - 2004-12-30 15:22:16
|
On Thu, 30 Dec 2004, Martin Spott wrote: > To my experience odds are good that these patches won't do any harm if > committed to the official PLIB source tree. Would you please have a > look ? I did submit all but one of the changes in the ports collection earlier, I don't know what became of that submission. One change should not be committed, which is the change that takes out the call to glIsValidContext(). Not all patches in the ports tree are desirable or even well thought out. By the way, I'm perfectly willing to take ownership of FreeBSD portability issues if people think it'll help. My sourceforge id is "driehuis". Cheers, -- Bert -- Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
|
From: Martin S. <Mar...@un...> - 2004-12-30 16:52:55
|
Bert Driehuis wrote: > One change should not be committed, which is the change that takes out > the call to glIsValidContext(). Not all patches in the ports tree are > desirable or even well thought out. I must admit that I can't tell if these patches conform with the PLIB developers' sense of doing "the right thing". I simply realized that applying all of these patches to the current CVS source tree make things work on FreeBSD and appear not to break anything on other Unix platforms I have access to (well, PLIB doesn't build at all on certain platforms ....). So I assume they're not a bad choice. I'll investigate on the glIsValidContext call next year (what a funny phrase :-) 'My' FreeBSD box is currently turned off and out of reach. Thanks for responding, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Bert D. <dri...@pl...> - 2004-12-30 17:14:15
|
Hi Martin, >> One change should not be committed, which is the change that takes out >> the call to glIsValidContext(). Not all patches in the ports tree are >> desirable or even well thought out. > > I must admit that I can't tell if these patches conform with the PLIB > developers' sense of doing "the right thing". Actually, it sometimes happens that ugly hacks sneak into the ports collection that "make it work" without fixing the underlying cause. This is one such case. > I simply realized that > applying all of these patches to the current CVS source tree make > things work on FreeBSD and appear not to break anything on other Unix > platforms I have access to (well, PLIB doesn't build at all on certain > platforms ....). So I assume they're not a bad choice. And here too, each change has to be evaluated individually. You cannot make an omelet without breaking eggs, but even simple changes like the "#include <netinet/in.h>" one will have to be announced on the list so that people can be prepared for potential breakage, or have the chance to recommend against the change. Of course, if no-one in the Plib team uses FreeBSD themselves, such changes tend to fall by the wayside, which is why I volunteered. I have lots of experience in being conservative in applying patches. It's a skill I acquired when working for chemical plants :-) > I'll investigate on the glIsValidContext call next year (what a funny > phrase :-) > 'My' FreeBSD box is currently turned off and out of reach. I can tell you off the top off my head (and hopefully correctly :-) glIsValidContext() fails when there is a mismatch in the pthread implementation between different libraries used by Plib. By commenting out this call, the application will start up even if conflicting pthread libraries are being used. Needless to say, the conflicting libraries can still blow up in your face, only you won't know what caused it. My memory may be off so please research it anyway. I'd really have to do a fresh FlightGear build to verify the above assertion. In the case of FlightGear on FreeBSD, all of plib, simgear and flightgear _must_ be built with the -pthread flag. I've not come round to building the whole thing recently so I don't know how things are currently (last time I tried, I gave up after some code in Flightgear wouldn't build on FreeBSD 5.3, but I will try again soon). Cheers, -- Bert -- Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
|
From: Martin S. <Mar...@un...> - 2004-12-30 17:40:50
|
Bert Driehuis wrote: > And here too, each change has to be evaluated individually. You cannot > make an omelet without breaking eggs, but even simple changes like the > "#include <netinet/in.h>" one will have to be announced on the list so > that people can be prepared for potential breakage, or have the chance > to recommend against the change. I agree. With this background one could start with committing the patches against src/js/jsBSD.cxx and src/sl/slPortability.h because these obviously don't touch anything else. I just realize that the patch against src/net/netMessage.h is obsolete, it's just a duplicate, forget about that (I wonder why I didn't realize earlier), the patch against src/net/netSocket.cxx could be en "#ifdef __FreeBSD__"'d in a similar way as already present in netMessage.h line 50. > glIsValidContext() fails when there is a mismatch in the pthread > implementation between different libraries used by Plib. By commenting > out this call, the application will start up even if conflicting pthread > libraries are being used. To my understanding (as far as I remember the Changelog) the issue of different thread libraries has been resolved with FreeBSD-5.3 As I already mentioned, I'll try next year. > In the case of FlightGear on FreeBSD, all of plib, simgear and > flightgear _must_ be built with the -pthread flag. I've not come round > to building the whole thing recently so I don't know how things are > currently (last time I tried, I gave up after some code in Flightgear > wouldn't build on FreeBSD 5.3, but I will try again soon). Some FlightGear people were so kind to commit several patches to Sim/FlightGear recently, current CVS builds right out of the box if you have a working OpenAL and PLIB (I typically use OpenAL from the FreeBSD ports and PLIB from CVS). Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Steve B. <sjb...@ai...> - 2004-12-30 21:09:55
|
After these patches are in and tested, we should probably think about doing another PLIB release. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Norman V. <nh...@ca...> - 2004-12-30 21:36:04
|
Steve Baker writes: > > After these patches are in and tested, we should probably think about doing > another PLIB release. Good idea ! Anything else need looking into ? I have updated the 'current.tgz' to reflect your recent patches I have to remeber do this manually as SourceForge still isn't allowing cron jobs from user shell accounts. I could place my python script that does this in our projects directory so that others could run it after commiting changes if this would be helpful Norman |
|
From: Steve B. <sjb...@ai...> - 2004-12-31 14:09:27
|
Norman Vine wrote: > Steve Baker writes: > >>After these patches are in and tested, we should probably think about doing >>another PLIB release. > > > Good idea ! > > Anything else need looking into ? The things that are most pressing for me are: * PW needs a way to get into full-screen mode. * The SSG loader ought to honor ssgLoaderOptions. Beyond that, SSG needs a top-to-bottom rewrite for multiple textures and shaders - but that's not going to happen in this cycle. > I could place my python script that does this in our projects > directory so that others could run it after commiting changes > if this would be helpful Yes please! ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Norman V. <nh...@ca...> - 2004-12-31 14:37:19
|
Steve Baker writes: > > Norman Vine wrote: > > > I could place my python script that does this in our projects > > directory so that others could run it after commiting changes > > if this would be helpful > > Yes please! Done :-) It is kind of a brain dead script but .... it seems to work :-) < following from a bash shell on SourceForge > -bash-2.05b$ pwd /home/groups/p/pl/plib -bash-2.05b$ ls -l daily.py -rwxrwxr-x 1 nhv plib 2994 Dec 31 06:18 daily.py invoke it either directly from the plib project directory ./daily.py or from your SF home directory as /home/groups/p/pl/plib/daily.py and it should just do the right thing. I just tested it and it seems to work for 'me' as file owner, but I think I have the permissions right so that any of the PLib developers can invoke it Cheers Norman |
|
From: Norman V. <nh...@ca...> - 2004-12-31 16:59:47
Attachments:
pw_fullscreen.tgz
|
< topic changed to reflect issue discussed >
Steve Baker writes:
>
> The things that are most pressing for me are:
>
> * PW needs a way to get into full-screen mode.
attached find changed files for Windows that implement this :-)
Note "f" key should swap between fullscreen and windowed mode
in examples / src / pw_pui.exe
Does a Linux and an OSX developer have code todo this ?
Norman
|
|
From: Steve B. <sjb...@ai...> - 2004-12-31 19:21:13
|
Norman Vine wrote: > > Note "f" key should swap between fullscreen and windowed mode > in examples / src / pw_pui.exe > > Does a Linux and an OSX developer have code todo this ? No - and I'm told it's very difficult to do across all window managers in X. From what I understand (and I'm *not* an expert), you essentially have to shut down the window and open a new one. However if you did that in a running OpenGL application, you'd lose all of the textures, display lists, shaders, etc that had already been stored - so it's not trivial for PW. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Norman V. <nh...@ca...> - 2004-12-31 22:09:02
Attachments:
pwX11.tgz
|
Steve Baker writes: > > Norman Vine wrote: > > > > Note "f" key should swap between fullscreen and windowed mode > > in examples / src / pw_pui.exe > > > > Does a Linux and an OSX developer have code todo this ? > > No - and I'm told it's very difficult to do across all window > managers in X. From what I understand (and I'm *not* an expert), > you essentially have to shut down the window and open a new one. > > However if you did that in a running OpenGL application, you'd > lose all of the textures, display lists, shaders, etc that had > already been stored - so it's not trivial for PW. Hmm... I don't know any better ... and ... I don't have an X box so I can't test this ... but .... maybe the attached is a start. :-) Cheers Norman |
|
From: Martin S. <Mar...@un...> - 2004-12-30 22:02:38
|
Steve Baker wrote: > After these patches are in and tested, we should probably think about doing > another PLIB release. I welcome this idea ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Steve B. <sjb...@ai...> - 2004-12-30 21:08:08
|
Bert Driehuis wrote: > glIsValidContext() fails when there is a mismatch in the pthread > implementation between different libraries used by Plib. !!!! I think it's *far* more likely that there is a bug in the application you are using to test with. It's quite possible for a threaded application to open a GL context in one thread and do OpenGL calls in another thread. It's easy to imagine a situation where there would be a race hazard that would result in some thread implementations allowing the application to work as intended and other thread implementations to show up the problem that was there in the application all along. Turning off the glIsValidContext() would give such broken applications more time to sort out their problems so the race condition would be much less aparrent than it would otherwise be. I very much doubt that the thread library and/or OpenGL and/or PLIB is to blame in this case...although it's obviously possible. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Steve B. <sjb...@ai...> - 2004-12-30 21:01:18
|
Bert Driehuis wrote: > One change should not be committed, which is the change that takes out > the call to glIsValidContext(). Not all patches in the ports tree are > desirable or even well thought out. We have had continual trouble with that. There are two conflicting aspects to this - both related to broken OpenGL implementations. 1) Some implementations don't correctly respond to glIsValidContext - notably one version of Mesa and one of ATI's drivers...probably both relate to an underlying DRI issue. In the presence of that bug, no PLIB applications will run because the library believes there is no valid GL context and therefore refuses to run. 2) Some implementations allow OpenGL applications to do (illegal) OpenGL calls (glGetString(...) is a common one) without a valid GL context. This allows application program writers to make the common error of trying to find out what kind of graphics card they have BEFORE they've opened a GL context...or perhaps do some other operation before the GL context is opened. Then, when they move their code to a different graphics card or driver, the formerly working program crashes. In order to prevent the latter problem causing a crash inside PLIB (and typically, a complaint to our developers for something we didn't do wrong) - I put checks for valid GL contexts in all of the PLIB initXXX() functions. Then, at least we know that PLIB isn't at fault. So - the problem is that if we leave out the glIsValidContext check then programmers make this VERY common mistake - and don't notice it for months or years later - and blame it on us. If we leave the glIsValidContext check in, then we sometimes fail on broken OpenGL implementations. I prefer to leave the check in there and try to get OpenGL fixed wherever possible. > By the way, I'm perfectly willing to take ownership of FreeBSD > portability issues if people think it'll help. My sourceforge id is > "driehuis". That would be very useful. Do you need developer access to PLIB? ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Martin S. <Mar...@un...> - 2004-12-30 22:01:34
|
Hello Steve, Steve Baker wrote: > If we leave the glIsValidContext check in, then we sometimes fail > on broken OpenGL implementations. > > I prefer to leave the check in there and try to get OpenGL fixed > wherever possible. Thanks for your insight, your proposal makes much sense in the end. Still I'd suggest to run some tests at least against recent XOrg release in order to find out if it proves to be beneficial with real-world applications. Thanks again, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Steve B. <sjb...@ai...> - 2004-12-31 14:14:50
|
Martin Spott wrote: > Hello Steve, > > Steve Baker wrote: > > >>If we leave the glIsValidContext check in, then we sometimes fail >>on broken OpenGL implementations. >> >>I prefer to leave the check in there and try to get OpenGL fixed >>wherever possible. > > > Thanks for your insight, your proposal makes much sense in the end. > Still I'd suggest to run some tests at least against recent XOrg > release in order to find out if it proves to be beneficial with > real-world applications. Well, that's the thing. For existing (and therefore presumably, working) applications, there is no need for the check because they are already doing things right and the check will always succeed. However, for future applications, the check is very important to catch a very common class of errors. ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Bert D. <dri...@pl...> - 2004-12-31 00:36:30
|
On Thu, 30 Dec 2004, Steve Baker wrote:
>> By the way, I'm perfectly willing to take ownership of FreeBSD portability
>> issues if people think it'll help. My sourceforge id is "driehuis".
>
> That would be very useful. Do you need developer access to PLIB?
Yes, please!
> > glIsValidContext() fails when there is a mismatch in the pthread
> > implementation between different libraries used by Plib.
>
> !!!!
>
> I think it's *far* more likely that there is a bug in the application
> you are using to test with.
>
> It's quite possible for a threaded application to open a GL context in
> one thread and do OpenGL calls in another thread. It's easy to imagine
> a situation where there would be a race hazard that would result in some
> thread implementations allowing the application to work as intended and
> other thread implementations to show up the problem that was there in
> the application all along.
This is definitely a possibility. It is also possible that NVidia is
somehow involved (I'm using the NVidia binary-only libraries).
I'll really have to experiment changing one variable at a time, but
being able to build Flightgear from CVS would be a very good start :-)
For what it's worth, I think that _if_ there are legitimate uses of not
calling glIsValidContext, we should do something like this:
if (getenv("PLIB_SKIP_GLCHECK") != NULL) {
cout << "Skipping glIsValidContext: use at your own risk!\n";
} else {
if (!glIsValidContext()) {
cout << "ssgInit called without valid OpenGL context\n";
cout << "Set PLIB_SKIP_GLCHECK=yes in your environment to skip ";
cout << "this test AT YOUR OWN RISK\n";
}
}
Cheers,
-- Bert
--
Bert Driehuis -- dri...@pl... -- +31-20-3116119
If the only tool you've got is an axe, every problem looks like fun!
|
|
From: Steve B. <sjb...@ai...> - 2004-12-31 15:00:01
|
Bert Driehuis wrote:
>> That would be very useful. Do you need developer access to PLIB?
>
> Yes, please!
You have it - welcome to the team!
>> It's quite possible for a threaded application to open a GL context in
>> one thread and do OpenGL calls in another thread. It's easy to imagine
>> a situation where there would be a race hazard that would result in some
>> thread implementations allowing the application to work as intended and
>> other thread implementations to show up the problem that was there in
>> the application all along.
>
> This is definitely a possibility. It is also possible that NVidia is
> somehow involved (I'm using the NVidia binary-only libraries).
The nVidia binaries are pretty much the same for BSD and Linux - it's
hard to imagine there would be a difference there - and we have never
had these problems with nVidia under Linux.
> I'll really have to experiment changing one variable at a time, but
> being able to build Flightgear from CVS would be a very good start :-)
Yes.
> For what it's worth, I think that _if_ there are legitimate uses of not
> calling glIsValidContext,
...well, I'm not sure 'legitimate' is the right word - but there are reasons
*IF* you are working around a known bug in some other library...
> we should do something like this:
>
> if (getenv("PLIB_SKIP_GLCHECK") != NULL) {
> cout << "Skipping glIsValidContext: use at your own risk!\n";
> } else {
> if (!glIsValidContext()) {
> cout << "ssgInit called without valid OpenGL context\n";
> cout << "Set PLIB_SKIP_GLCHECK=yes in your environment to skip ";
> cout << "this test AT YOUR OWN RISK\n";
> }
> }
I think the 'else' clause still needs an 'exit()' or an 'assert' or something
to terminate execution.
People are very bad at noticing error messages - especially in interactive
programs that they launch from an icon or menu bar.
Before we had this check in the code, I'd get MANY emails from application
writers and end users complaining that "PLIB is crashing" on such-and-such
architecture - and generally, the quality of their error reports were so
bad that it would take weeks of emailing back and forth to track down what
was going wrong.
With the fatal error check, the application writer sees a clear problem the
very first time he introduces the bug. The error can't be ignored so he
MUST fix his program. This has reduced our maintenance traffic considerably.
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: Bram S. <br...@sa...> - 2004-12-31 06:44:15
|
Steve Baker wrote:
> So - the problem is that if we leave out the glIsValidContext check
> then programmers make this VERY common mistake - and don't notice it
> for months or years later - and blame it on us.
>
> If we leave the glIsValidContext check in, then we sometimes fail
> on broken OpenGL implementations.
>
> I prefer to leave the check in there and try to get OpenGL fixed
> wherever possible.
I would record the creation of a context in plib, and do your
context check as follows:
bool check_context()
{
if (opengl thinks context is ok)
return true;
if (plib has not yet created context)
WARNING: you should not use opengl without context. Fix your app.
return false;
WARNING: You are using a broken OGL implementation. Demand better drivers.
return true;
}
Of course, the last warning, you want to print only
once, and not every time the context is checked for
validity.
Bram
|
|
From: Steve B. <sjb...@ai...> - 2004-12-31 15:36:08
|
Bram Stolk wrote:
> I would record the creation of a context in plib, and do your
> context check as follows:
PLIB doesn't create the rendering context, we leave that up to
the windowing library (SDL, freeglut, FLTK, etc).
(Well...unless you use PLIB's PW library...in that case,
we *DO* create the rendering context - but SSG, FNT and
PUI (who make the glIsValidContext calls) are all independent
from PW - so we won't make that connection).
Since it's the application's responsibility to create a rendering
context, we merely check that he did it right as a defensive mechanism.
However, it's been a LONG time since I've seen a complaint about the
check under Linux - and I've never had complaints from Windows, IRIX
or Mac users. I thought that all 'recent' OpenGL implementations
had the problem licked. IIRC, the last time it showed up was a couple
of years ago with a RedHat release that used a 'hacked' version of Mesa
instead of the officially sanctioned release from the Mesa team.
That's why I'm suspicious that this is coming from the FreeBSD
community. They may either have a newly broken OpenGL implementation
or (*FAR* more likely IMHO) a thread mechanism that exposes an existing
race condition in some particular application they are testing with.
That makes sense because they have suspicions that threads are somehow
implicated here - and a program that used threading extensively would
be quite capable to doing something dumb like opening the GL context
in the 'main' program *AFTER* launching a parallel thread that would
render to that context. A bug like that would evade PLIB's check - and
(depending on the precise thread scheduling) might work perfectly under
Windows and Linux. However, FreeBSD has a different threading mechanism
with utterly different scheduling - so a broken program that SEEMED to
work OK under Linux and Windows could EASILY be broken by a different
scheduler.
If that hypothesis is correct then removing PLIB's check would be a very
bad thing indeed. It would allow the application to run without crashing,
but OpenGL calls made before the rendering context was opened would be
ignored by 'correctly functioning' OpenGL implementations. You might
see odd flakey rendering problems - but maybe the application would
appear to work OK.
Anyhow...
To make this *utterly* clear:
1) PLIB is doing *exactly* the right thing right now.
2) All we are discussing is a kludge to work around someone elses problem.
3) In order to fix this problem, SOMEONE has to make a change. It's either
the OpenGL/Windowing library/driver, the threading library, the application
or us.
However we *KNOW* the problem isn't ours - we are only the good guys
who are detecting the problem.
Why then would you change the one part of the system that's letting
you find the bug? If we kludge PLIB then the underlying problem
will probably never be found.
The only reason this is even being thought about is that we are a
relatively small, responsive team and someone can see a one-line
kludge to get something half-assedly working.
So, I think we should leave the check in place and punt the problem to
whoever broke the system!
---------------------------- Steve Baker -------------------------
HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...>
HomePage : http://www.sjbaker.org
Projects : http://plib.sf.net http://tuxaqfh.sf.net
http://tuxkart.sf.net http://prettypoly.sf.net
-----BEGIN GEEK CODE BLOCK-----
GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M-
V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++
-----END GEEK CODE BLOCK-----
|
|
From: Bert D. <dri...@pl...> - 2004-12-31 15:17:21
|
On Fri, 31 Dec 2004, Steve Baker wrote: >>> That would be very useful. Do you need developer access to PLIB? >> >> Yes, please! > > You have it - welcome to the team! Cool! I'll tread carefully. But for now, I'm gonna take a sabattical for the rest of this year. :-) > I think the 'else' clause still needs an 'exit()' or an 'assert' or something > to terminate execution. I meant to include the exit. 't was late.... I'll shut up about it anyway until I have hard facts. Cheers, -- Bert -- Bert Driehuis -- dri...@pl... -- +31-20-3116119 If the only tool you've got is an axe, every problem looks like fun! |
|
From: Steve B. <sjb...@ai...> - 2004-12-31 15:44:11
|
Bert Driehuis wrote: > On Fri, 31 Dec 2004, Steve Baker wrote: >> You have it - welcome to the team! > > Cool! I'll tread carefully. But for now, I'm gonna take a sabattical for > the rest of this year. :-) Sorry - vacation requests have to be submitted at least one calendar month in advance, signed by your team leader, initialed by your line manager, then buried under six inches of compost and watered regularly. Oh - wait, no. That's my day job. :-( ---------------------------- Steve Baker ------------------------- HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://www.sjbaker.org Projects : http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net -----BEGIN GEEK CODE BLOCK----- GCS d-- s:+ a+ C++++$ UL+++$ P--- L++++$ E--- W+++ N o+ K? w--- !O M- V-- PS++ PE- Y-- PGP-- t+ 5 X R+++ tv b++ DI++ D G+ e++ h--(-) r+++ y++++ -----END GEEK CODE BLOCK----- |
|
From: Martin S. <Mar...@un...> - 2004-12-31 16:56:56
|
Bert Driehuis wrote: > Cool! I'll tread carefully. But for now, I'm gonna take a sabattical for > the rest of this year. :-) Great, you could start your journey by merging the three remaining patches in ftp://ftp.uni-duisburg.de/FlightGear/Devel/PLIBFreeBSD/ :-) I don't get any difficulties with the inclusion of <netinet/in.h> (on FreeBSD, Solaris, IRIX and Linux) but I have to admit that I never did any sort of networking I/O since I got aware of these patches, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
|
From: Martin S. <Mar...@un...> - 2005-01-03 10:07:51
|
Martin Spott wrote: > Great, you could start your journey by merging the three remaining > patches in ftp://ftp.uni-duisburg.de/FlightGear/Devel/PLIBFreeBSD/ I wish everyone a happy new year, PLIB CVS builds fine on FreeBSD-5.3 after applying these patches, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -------------------------------------------------------------------------- |
×
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