This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: changes in 32-bit Cygwin OpenGL causing crashes?

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 
of Cygwin.

Notes at:

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.

Lloyd Wood

----- Original Message -----
From: Stephen John Smoogen <>
Sent: Thursday, 26 May 2016, 2:09
Subject: Re: changes in 32-bit Cygwin OpenGL causing crashes?

On 25 May 2016 at 02:08,  <> 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:
> FAQ:        
> Documentation:
> Unsubscribe info:

Stephen J Smoogen.

Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]