This is the mail archive of the
mailing list for the Cygwin project.
Re: changes in 32-bit Cygwin OpenGL causing crashes?
- From: <lloyd dot wood at yahoo dot co dot uk>
- To: Stephen John Smoogen <smooge at gmail dot com>, "cygwin at cygwin dot com" <cygwin at cygwin dot com>
- Date: Fri, 27 May 2016 03:01:27 +0000 (UTC)
- Subject: Re: changes in 32-bit Cygwin OpenGL causing crashes?
- Authentication-results: sourceware.org; auth=none
- References: <538382235 dot 210794 dot 1464156496492 dot JavaMail dot yahoo dot ref at mail dot yahoo dot com> <538382235 dot 210794 dot 1464156496492 dot JavaMail dot yahoo at mail dot yahoo dot com> <CANnLRdgB9nrJp2ZXKK3Bb_=RvnGsVepJaf3Ms2cNRAc0Ouc4eQ at mail dot gmail dot com>
- Reply-to: <lloyd dot wood at yahoo dot co dot uk>
It's odd, the amount of extra support that Cygwin needs.
Okay, OpenGL is broken in 32-bit cygwin, not for the first
I'm unsure if OpenGL is broken in 64-bit cygwin, because
the piping my applications use is broken in 64-bit cygwin -
and only there. Not in any other linux or unix I've run on.
So, it's rather tempting to blame 64-bit Cygwin.
But the OpenGL code is clearly obviously different
and later in 64-bit Cygwin, because it builds to different
function names (dropped a bunch of EXTs.) That's... odd.
But in any case, we have a -noopengl flag just to work
around OpenGL segfaulting in 32-bit Cygwin (and whether
64-bit segfaults is unknown, because piping problems.).
And there are graphical glitches I see in 32-bit Cygwin
Tcl/Tk, but not in 64-bit Cygwin Tcl/Tk or anywhere else,
32- or 64-bit, in Linux/Unix land.
Those are the major things that come to mind when I think
where I try and suggest to users that Cygwin is not
their best choice. Really.
It's been over fifteen years of 'under construction' so far.
----- Original Message -----
From: Stephen John Smoogen <email@example.com>
To: firstname.lastname@example.org; email@example.com
Sent: Thursday, 26 May 2016, 2:09
Subject: Re: changes in 32-bit Cygwin OpenGL causing crashes?
On 25 May 2016 at 02:08, <firstname.lastname@example.org> wrote:
>> It seems still the same problem with dri-drivers
>> probably caused by LLVM 3.7
> Unfortunately, the dri-driver versions available in the installer
> depend on LLVM 3.7, so, even though reverting back to LLVM 3.5
> is offered when you select llvm, you can't pull in a dri-driver
> that works with that older version of LLVM to test that hypothesis.
> So, not much point to offering that older version of LLVM.
dri-driver via LLVM is a hack on top of a hack on top of a hack as the
developer of the software will tell you. It works in the use cases he
develops for but outside of that you are very much all alone. So even
trying to have a 'known' good is hard for this because what worked on
your laptop/system may not work at all on any other one.
Heck it might not even work when the Windows OS underneath does an
update even though the hardware worked. To quote the road sign
Expect problems. Road construction ahead.
If you are needing better stability then you need to staff up
somewhere to have people to fix those problems.
> Regardless of the fact that OpenGL is broken (again), this is
> really a problem with Cygwin as a perennial work-in-progress
> and its (lack of) version control.
> I'd like to be able to download a stable-known-to-work-on
> a-specified date golden-master Cygwin, without incremental
> upgrades, and revert to that known-to-work Cygwin if needs
> be. Once every six months? I'd be good with that.
> Lloyd Wood
> Problem reports: http://cygwin.com/problems.html
> FAQ: http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Stephen J Smoogen.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple