Re: Invalid tm_zone from localtime() when TZ is not set
On Wed, 25 May 2016 22:02:50 +0200, Hans-Bernhard Bröker wrote:
> On May 25 11:28, KOBAYASHI Shinji wrote:
>> The intention of the following code in tzsetwall() should be to pick
>> up UPPERCASE letters "in ASCII range":
> Are you sure you're not mixing ASCII with '8-bit character' range there?
I'm not sure if non-ASCII 8-bit characters are allowed as TZ
names. I just guessed the intention from the fact isupper() is used,
and from the description of isupper() man page:
- isupper is a macro which classifies ASCII integer values by table
lookup.
- It is defined only when isascii(c) is true or c is EOF.
However, the implementation of isupper() seems to work for 8-bit
characters even if isascii() is false. Does the man page need some
changes?
> A proper solution may have to be more like this:
> int mapped = wctob(*src);
> /* this call is safe now because of how wctob() works: */
> if (isupper(mapped)) {
>*dst++ = (unsigned char)mapped;
> }
Thank you for pointing out wctob(). I'm in favor of fixing this way.
On Wed, 25 May 2016 10:44:30 +0200, Corinna Vinschen wrote:
> However, testing this with GLibc it turns out that GLibc's towlower does not
> transform the character but returns 0xff21. Can anybody explain to me why?
It seems that it depends on locale. The man page (on Linux) says:
The behavior of towlower() depends on the LC_CTYPE category of the
current locale.
I observed that it returns 0xff41 when LANG=ja_JP.UTF-8, and 0xff21
when LANG=C.
Cygwin's implementation (and man page) does not seem to depend on
locale.
Regards,
KOBAYASHI Shinji.
--
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
[ANNOUNCEMENT] Updated: dos2unix 7.3.4-1
CHANGES SINCE LAST RELEASE: === New upstream release. * Safer temporary file creation on Windows. * Code cleanup. * Updated translations. homepage: http://waterlan.home.xs4all.nl/dos2unix.html license: 2-clause BSD (FreeBSD) -- Erwin Waterlander http://waterlan.home.xs4all.nl/ -- 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
Re: Invalid tm_zone from localtime() when TZ is not set
Am 25.05.2016 um 10:44 schrieb Corinna Vinschen:
On May 25 11:28, KOBAYASHI Shinji wrote:
Any other comments on this topic? Let me explain my proposal again.
The intention of the following code in tzsetwall() should be to pick
up UPPERCASE letters "in ASCII range":
Are you sure you're not mixing ASCII with '8-bit character' range there?
if (isupper(*src)) *dst++ = *src;
NOTE: src is wchar_t *, dst is char *.
As Csaba Raduly pointed out, isw*() functions should be the first
choice if they achieve the desired behavior (select uppercase AND
ASCII).
But it doesn't, so it's not.
However, iswupper() does not fit for this purpose, as it
returns 1 for L'\uff21' for example. And I could not find isw*()
In that case, wouldn't it make sense to fix iswupper in the first place?
I don't believe it's been shown to be broken, so there's no need to fix it.
Apart from that, we can workaround all problems in tzsetwall by just
checking for
if (*src >= L'A' && *src <= L'Z')
While that may be possible if it really is ASCII you're looking for,
it's perverting the whole reason and exist: to make
tests like this as independent of the actual character encoding as possible.
Here's what I wrote last week, but apparently only to Csaba Raduli:
Am 20.05.2016 um 09:09 schrieb Csaba Raduly:
> If the type of those members is WCHAR[] then using isascii() /
> isupper() on them is just plain wrong.
Absolutely. The argument type of isupper() and friends is 'int', not
'unsigned char'. But the _only_ allowed argument values are those in
the range of unsigned char, plus EOF. For typical systems, that means
the allowed argument range of is*() is -1 ... 255 inclusive. Calling
these Standard Library functions with any other argument causes
undefined behaviour.
That leaves three sensible ways of calling isupper() in portable code:
*) isupper(foo) # where type of foo is unsigned char
*) isupper((unsigned char)bar) # where bar is signed char, or plain char
*) isupper(baz) # where baz was got from fgetc() or similar
All other call patterns are plain and simply wrong, or at least
non-portable. In particular, passing a wchar_t to any of the
function is wrong every time.
> The correct function to use would be iswupper().
Actually, the is*upper() isn't even the actual problem here. The whole
idea of copying a wchar_t string into a char one, element by element, is
most likely nonsensical. A wchar_t cannot be assumed to just fit into a
char, regardless whether iswupper() returned true on it or not. E.g.
what do we expect this to do with an upper-case Greek or Cyrillic letter?
A proper solution may have to be more like this:
int mapped = wctob(*src);
/* this call is safe now because of how wctob() works: */
if (isupper(mapped)) {
*dst++ = (unsigned char)mapped;
}
>> So, I propose to call isascii() to assure the wchar_t fits in the
>> range of ASCII before calling isupper().
Calling isascii() would be wrong for the same reasons calling isupper() is.
--
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
Re: Question about XP support
On Wed, May 25, 2016 at 10:56 AM, Corinna Vinschen wrote: > 2.6, probably. This is much more than you got back in the days when > we dropped support for 9x, NT4, W2K ;) I'll be happy with that :) -- Erik -- 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
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 >> https://sourceware.org/ml/cygwin/2016-04/msg00283.html >> >> 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 > http://savi.sf.net/ > > -- > 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 FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: changes in 32-bit Cygwin OpenGL causing crashes?
On 25 May 2016 at 02:56, wrote: > http://www.redhat.com/services/custom/cygwin/support/ > OpenGL and drivers are not on the supported list. > > I suppose cygwin problems will all be moot once the > Windows 10+Canonical Ubuntu is well-established, but we're not there yet. > https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspace-for-windows-developers/ > It will if you don't want to interact with the higher up Windows system in many ways. The Ubuntu 'hack' is much more like you are running a container of Linux on your Windows system so you can do certain things inside that container, but interacting with the Windows system is limited to what you can do. Now that might meet your needs completely. > > Lloyd Wood > http://savi.sf.net > > - Original Message - > From: Andrey Repin > To: lloyd.w...@yahoo.co.uk; cygwin@cygwin.com > Sent: Wednesday, 25 May 2016, 16:39 > Subject: Re: changes in 32-bit Cygwin OpenGL causing crashes? > > Greetings, lloyd.w...@yahoo.co.uk! > > >>> It seems still the same problem with dri-drivers >>> https://sourceware.org/ml/cygwin/2016-04/msg00283.html >>> >>> 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. > >> 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. > > RedHat offers paid support for Cygwin, you know. > > P.S. > And it would be really wonderful, if you teach your mail client to not break > threading. > > > -- > With best regards, > Andrey Repin > Wednesday, May 25, 2016 09:38:43 > > Sorry for my terrible english... > > -- > 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 FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Question about XP support
On May 25 10:22, Erik Soderquist wrote: > On Wed, May 25, 2016 at 9:56 AM, Stephen John Smoogen wrote: > > > > On 25 May 2016 at 06:07, Corinna Vinschen wrote: > > > Uh oh, bad timing... > > > > > > The next release 2.5.2 introduces the first non-XP compatible code. > > > It's in a seldom used corner of the code and it doesn't require > > > functions unavailable on XP, so it will very likely not break 99% of the > > > existing applications yet. > > > > > > But the next release after will very likely break XP support entirely. > > > > Would this be something to move to 3.x because there seems to be a lot > > of people who come onto the list a lot. That way they know they can > > use 2.5.1 and that is the last 'stable' release they need to 'fork' > > from as say Cygnus-XP1 to keep going? > > I like this idea. I too have some isolated XP VM stations (mine > deliberately have zero network connection; "defender updates" do NOT > close security holes) that I currently plan to continue using until > I've learned enough programming myself to rewrite the windows only > utilities I have running in these stations. A version change from > from 2.x to 3.x at the official end of XP support would make it a very > clean marker. 2.6, probably. This is much more than you got back in the days when we dropped support for 9x, NT4, W2K ;) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Question about XP support
On May 25 09:56, Stephen John Smoogen wrote: > On 25 May 2016 at 06:07, Corinna Vinschen wrote: > > On May 24 20:38, Herbert Stocker wrote: > >> On 24.05.2016 18:44, Jim Reisert AD1C wrote: > >> > I thought that support for Windows XP had been removed from Cygwin. > >> > >> No, has not yet been removed. > >> And i'm sooo happy about this. > > > > Uh oh, bad timing... > > > > The next release 2.5.2 introduces the first non-XP compatible code. > > It's in a seldom used corner of the code and it doesn't require > > functions unavailable on XP, so it will very likely not break 99% of the > > existing applications yet. > > > > But the next release after will very likely break XP support entirely. > > Would this be something to move to 3.x because there seems to be a lot > of people who come onto the list a lot. That way they know they can > use 2.5.1 and that is the last 'stable' release they need to 'fork' > from as say Cygnus-XP1 to keep going? The XP-breaking release will certainly be a major release. I doubt it's called 3.0, though. 2.6 is more likely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: Question about XP support
On Wed, May 25, 2016 at 9:56 AM, Stephen John Smoogen wrote: > > On 25 May 2016 at 06:07, Corinna Vinschen wrote: > > Uh oh, bad timing... > > > > The next release 2.5.2 introduces the first non-XP compatible code. > > It's in a seldom used corner of the code and it doesn't require > > functions unavailable on XP, so it will very likely not break 99% of the > > existing applications yet. > > > > But the next release after will very likely break XP support entirely. > > Would this be something to move to 3.x because there seems to be a lot > of people who come onto the list a lot. That way they know they can > use 2.5.1 and that is the last 'stable' release they need to 'fork' > from as say Cygnus-XP1 to keep going? I like this idea. I too have some isolated XP VM stations (mine deliberately have zero network connection; "defender updates" do NOT close security holes) that I currently plan to continue using until I've learned enough programming myself to rewrite the windows only utilities I have running in these stations. A version change from from 2.x to 3.x at the official end of XP support would make it a very clean marker. -- Erik -- 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
Re: Question about XP support
On 25 May 2016 at 06:07, Corinna Vinschen wrote: > On May 24 20:38, Herbert Stocker wrote: >> On 24.05.2016 18:44, Jim Reisert AD1C wrote: >> > I thought that support for Windows XP had been removed from Cygwin. >> >> No, has not yet been removed. >> And i'm sooo happy about this. > > Uh oh, bad timing... > > The next release 2.5.2 introduces the first non-XP compatible code. > It's in a seldom used corner of the code and it doesn't require > functions unavailable on XP, so it will very likely not break 99% of the > existing applications yet. > > But the next release after will very likely break XP support entirely. Would this be something to move to 3.x because there seems to be a lot of people who come onto the list a lot. That way they know they can use 2.5.1 and that is the last 'stable' release they need to 'fork' from as say Cygnus-XP1 to keep going? > > Corinna > > -- > Corinna Vinschen Please, send mails regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat -- Stephen J Smoogen. -- 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
Re: changes in 32-bit Cygwin OpenGL causing crashes?
On 25 May 2016 at 02:39, Andrey Repin wrote: > Greetings, lloyd.w...@yahoo.co.uk! > >>> It seems still the same problem with dri-drivers >>> https://sourceware.org/ml/cygwin/2016-04/msg00283.html >>> >>> 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. > >> 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. > > RedHat offers paid support for Cygwin, you know. > I don't know if that is true anymore. What Lloyd is asking for may also be a larger project than what was also offered before. The question is whether there are enough people who would be interested in this sort of product for it to be useful. > P.S. > And it would be really wonderful, if you teach your mail client to not break > threading. > > > -- > With best regards, > Andrey Repin > Wednesday, May 25, 2016 09:38:43 > > Sorry for my terrible english... > > > -- > 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 FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[ANNOUNCEMENT] Updated: Git v2.8.3-1
Version 2.8.3-1 of Git has been uploaded and should be coming soon to a mirror near you. This update includes the following packages: - git - git-cvs - git-debuginfo - git-email - git-gui - gitk - git-svn This is an update to the latest upstream release. For a full list of the upstream changes in this release, please refer to the upstream changelogs: https://git.kernel.org/cgit/git/git.git/tree/Documentation/RelNotes https://kernel.googlesource.com/pub/scm/git/git.git/+/master/Documentation/RelNotes/ https://github.com/git/git/tree/master/Documentation/RelNotes Enjoy! Adam -- 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
Re: Question about XP support
On May 24 20:38, Herbert Stocker wrote: > On 24.05.2016 18:44, Jim Reisert AD1C wrote: > > I thought that support for Windows XP had been removed from Cygwin. > > No, has not yet been removed. > And i'm sooo happy about this. Uh oh, bad timing... The next release 2.5.2 introduces the first non-XP compatible code. It's in a seldom used corner of the code and it doesn't require functions unavailable on XP, so it will very likely not break 99% of the existing applications yet. But the next release after will very likely break XP support entirely. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
'setxkbmap us -variant colemak' does not work
Hello. The command 'setxkbmap us –variant colemak' does not work (x86 and amd64). Returns error message: 'Error loading new keyboard description' Thank you. Best Regards Karl -- 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
Re: [ANNOUNCEMENT] mesa 11.0.9-2
On 13/04/2016 04:33, Yaakov Selkowitz wrote: On 2016-04-12 10:20, Marco Atzeri wrote: we found a case where the 32bit is segfaulting while dri-drivers-11.0.9-1 works fine. For reference: https://cygwin.com/ml/cygwin/2016-04/msg00245.html https://cygwin.com/ml/cygwin/2016-04/msg00251.html To replicate with octave is enough : run from xterm /usr/bin/octave-cli-4.0.1.exe x=1:100; plot(x,x) However I see that also mesa-demos segfault $ cd /usr/lib/mesa-demos $ ./quad-clip.exe GL_RENDERER = Gallium 0.4 on llvmpipe (LLVM 3.7, 256 bits) GL_VERSION= 3.0 Mesa 11.0.9 GL_VENDOR = VMware, Inc. Segmentation fault (core dumped) I can reproduce this on 32-bit but not 64-bit, and the same happens with 11.1.2. It may be an issue with LLVM 3.7 (11.0.9-1 was built with 3.5) but without a useful backtrace it will be hard to pin down. Hi Yaakov, until the root cause is not pinned down, can you re-put 11.0.9-1 as current for 32bit and leave all the new version as tests ? With current 11.2.2-1 and previous 11.2.1-1 both not working we have an issue. Regards Marco -- 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
Re: changes in 32-bit Cygwin OpenGL causing crashes?
On 25/05/2016 08:08, lloyd.w...@yahoo.co.uk wrote: It seems still the same problem with dri-drivers https://sourceware.org/ml/cygwin/2016-04/msg00283.html 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. 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. Feel free to propose a solution compatible with the lack of dedicated man power. The package per maintainer statistics can highlight the workload issue: 2406 Yaakov Selkowitz 171 Jari Aalto 142 Achim Gratz 141 Marco Atzeri 82 Ken Brown 70 Dr. Volker Zell 44 Achim Gratz/Yaakov Selkowitz 39 Achim Gratz/Ken Brown 36 Corinna Vinschen 26 Andrew Schulman 22 Jonathan Yong 22 David Rothenberger 20 Eric Blake 19 Jon Turney 17 David Stacey Total 3388 Of course not all the packages weight the same; Jon and Corinna have very heavy loads 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. Feel free to use the Time Machine http://www.fruitbat.org/Cygwin/#cygwintimemachine kindly provided by Peter Lloyd Wood http://savi.sf.net/ -- 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 -- 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
Re: Invalid tm_zone from localtime() when TZ is not set
On May 25 11:28, KOBAYASHI Shinji wrote: > > Any other comments on this topic? Let me explain my proposal again. > > The intention of the following code in tzsetwall() should be to pick > up UPPERCASE letters "in ASCII range": > > if (isupper(*src)) *dst++ = *src; > > NOTE: src is wchar_t *, dst is char *. > > As Csaba Raduly pointed out, isw*() functions should be the first > choice if they achieve the desired behavior (select uppercase AND > ASCII). However, iswupper() does not fit for this purpose, as it > returns 1 for L'\uff21' for example. And I could not find isw*() In that case, wouldn't it make sense to fix iswupper in the first place? It relies on the towupper function in newlib/libc/ctype/towlower.c. However, I don't understand the example. 0xff21 is FULLWIDTH LATIN CAPITAL LETTER A. This is very certainly an uppercase letter so towlower transforms it to 0xff41, FULLWIDTH LATIN SMALL LETTER A. However, testing this with GLibc it turns out that GLibc's towlower does not transform the character but returns 0xff21. Can anybody explain to me why? Apart from that, we can workaround all problems in tzsetwall by just checking for if (*src >= L'A' && *src <= L'Z') So, yeah, I can do the above change to tzsetwall and it would be nice if somebody could take a critical look over newlib's towlower.c and toupper.c. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat signature.asc Description: PGP signature
Re: changes in 32-bit Cygwin OpenGL causing crashes?
http://www.redhat.com/services/custom/cygwin/support/ OpenGL and drivers are not on the supported list. I suppose cygwin problems will all be moot once the Windows 10+Canonical Ubuntu is well-established, but we're not there yet. https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspace-for-windows-developers/ Lloyd Wood http://savi.sf.net - Original Message - From: Andrey Repin To: lloyd.w...@yahoo.co.uk; cygwin@cygwin.com Sent: Wednesday, 25 May 2016, 16:39 Subject: Re: changes in 32-bit Cygwin OpenGL causing crashes? Greetings, lloyd.w...@yahoo.co.uk! >> It seems still the same problem with dri-drivers >> https://sourceware.org/ml/cygwin/2016-04/msg00283.html >> >> 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. > 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. RedHat offers paid support for Cygwin, you know. P.S. And it would be really wonderful, if you teach your mail client to not break threading. -- With best regards, Andrey Repin Wednesday, May 25, 2016 09:38:43 Sorry for my terrible english... -- 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
