Re: Generating Linux Compatible binaries

[Michael Enright]

On Fri, Dec 3, 2021 at 8:51 AM Goswami-EXT, Himanshu
 wrote:
>
> Hi,
>
> I want to generate the Linux compatible binaries on Windows System.
> Cygwin is a cross compiler which offers POSIX environment.
> But I could not find any Unix libraries to generate the Linux compatible 
> binaries.
> Could you please advice any steps that I can follow?
>

Eliot Moss recommends a VM and that's a good option.

Another option is to use Cygwin to host a cross compiler. I  have used
Cygwin to build and install cross compilers that ran on Cygwin and
built code for my Raspberry Pi 2. There are many tutorials on building
and creating cross compilers and I won't try to equal them. But this
is a versatile method. If the target Linux was one that runs on a
different processor and a virtual machine would be inefficient or lack
the resources to carry out the build, then running a cross compiler on
your Windows machine, under Cygwin or otherwise, might be an option to
consider.

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: GLX and libX11

[Michael Enright]

On Sun, Jan 24, 2021 at 5:38 AM Marco Atzeri via Cygwin
 wrote:
>
>
> Have you started the program from inside a XTerm  with a running
> XServer ?
>

I compiled and ran the program in a mintty window, while X server was
started and the environment variable DISPLAY was set. It ran
perfectly. I don't have XTerm installed, it would probably have taken
care of the DISPLAY variable.

I started a second mintty window and started the program from there
without setting DISPLAY, and the program complained "cannot connect to
X server".

I think Rafał started the program from a shell which had DISPLAY set,
but @Rafał if you could confirm that it would help a bit. I think some
Cygwin X components may be missing. The reason I think this is the
message that says the Windows DRI extension is missing, which I guess
is awfully specific.

It occurs to me that starting XTerm would be a useful diagnostic, but
if "Windows DRI" is missing, XServer probably can't start, never mind
"Windows DRI extension"
--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Multiple problems (probably) starting up new installation

[Michael Enright]

On Sun, Oct 21, 2018 at 3:50 PM Andrey Repin  wrote:
>
> I would actually suggest renaming the system user, if possible.

All my previous setups used a silly name like "Mike" that was not
linked to a Microsoft account but still chosen automatically, or my
preferred username "menright" if I noticed the chance to set the name
myself during initial Windows setup. These setups don't seem to have
been as difficult to get started with.

It seems like everyone who faces this (based on more extensive
searching starting from your suggestion to rename the account) ends up
creating a local account with a well-chosen name.  The data have to be
transferred from one account to the other if there is anything to
transfer. The advantages, if there are any, of a link to a Microsoft
account apparently can be achieved by linking the local account to the
desired Microsoft account  after the local account is set up. I don't
see anything about actually renaming the account.

This seems like a good place to start:
https://superuser.com/questions/1129165/how-to-rename-a-user-account-that-is-already-linked-to-a-microsoft-account

>
> > rwx---+ 1 menright Mike Enright 0 Oct 21 15:02 CMakeLists.txt
>
> the "+" says that there's extended ACL present. So, nothing odd.
>

The Windows view of this set of permissions (070 plus whatever is in
the rest of the ACL) seems to be that Windows programs can't do very
much with this file. So it's odd from that POV and I wonder if that
was caused by my renaming the "Cygwin account". Using cacls I see the
Windows username in some of the entries and I don't see the cygwin
username in any. I know that I can get a workable ACL with chmod but I
can see that executables built by the compiler are not executable,
either by name from cygwin bash or by double click from Windows
Explorer. This is the first few lines from cacls:
$ cacls moneymaker
C:\cygwin64\home\menright\moneymaker NULL SID:(DENY)(special access:)
  READ_CONTROL
  FILE_READ_EA
  FILE_WRITE_EA
  FILE_EXECUTE
  FILE_DELETE_CHILD

--
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

Multiple problems (probably) starting up new installation

[Michael Enright]

I have a few files that I want to compile and run in a new Windows 10 setup.
I setup cygwin64 and copied the files to a subdirectory of my home directory.
I noticed that my prompt indicated that my home directory was
"/home/Mike Enright". I decided that in the long run that would be
bad.
So I followed a tip from Stack Overflow [1]to use /etc/passwd to fix
this. Apparently the idea is to map the Windows SID to my desired user
name "menright" instead of "\"Mike Enright\"".
And also rename the created home directory accordingly.
So now I have /home/menright and some files under there and
/etc/password contains a line that maps an SID to menright.

Due to a problem out of scope of this list Eclipse launches notepad
when I want to edit CMakeLists.txt. Then Notepad says "You do not have
permission to open this file"

I noticed "ls -l CMakeLists.txt" gets:
rwx---+ 1 menright Mike Enright 0 Oct 21 15:02 CMakeLists.txt
It's really odd that the user permissions are zero.

So I want notepad to have permission to open this file on my behalf.
Oddly I made a file called "me" with touch and I was able to edit that
with notepad.

I would also ask any advice. I fear that this permissions issue is due
to some underlying issue that I need to nip in the bud before I get
too much work done.

I think I'd also like to have my personal group "Mike Enright" renamed
to "menright" just to be sane.

[1] https://stackoverflow.com/questions/19613654/rename-change-cygwin-username

--
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: UTF-8 character encoding

[Michael Enright]

On Mon, Jun 25, 2018 at 11:33 AM, Lee  wrote:
> I'm still trying to figure utf-8 out, but it seems to me that 0x0 -
> 0xff is part of the utf-8 encoding.

I don't see how you arrived at this. An initial byte of 0xFF is not
the initial byte of any valid UTF-8 byte sequence. And it doesn't
conform with the statement you have later:

>  An easy way to remember this transformation format is to note that the
>  number of high-order 1's in the first byte is the same as the number of
>  subsequent bytes in the multibyte character:

This is true, but there is also a zero bit that ends the
high-order-1's bit string, which means that 0xFF is not a valid lead
byte. 0x7F is the highest byte value that you can have as a
single-byte UTF8 string.

Perhaps your statement about 0-0xFF was meant to be read differently.

Thomas Wolff's note seems to be objecting to the inclusion of
characters above U+10 which isn't legal UTF-8, but was in the
original proposal. Otherwise your table rows 1-4 is correct.

The standards such as IETF RFC-3629 are easy enough to read, so I
recommend using them and citing them to others instead of trying to
summarize.

--
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: Defaulting to stabs debug output from AS Cygwin64

[Michael Enright]

On Tue, May 15, 2018 at 5:58 AM, cyg Simple  wrote:
>
> Years of work tells me to not trust the default of any option.  You
> should be specific.

I have a few years under my belt (come to think of it they are
threatening to engulf my belt). For work, I'd do what's necessary to
integrate the little thing into the big thing. For this I don't want
to work too hard on side issues unless I decide they are interesting
side issues.

>
> The dwarf format isn't supported by native tools.  I think COFF should
> be the default but that is just me and I don't maintain the distribution
> of GCC.

The GCC driver uses -gdwarf2 if you do 'gcc -g' on a .s file. Using
-gdwarf2 with assembly code manually or through gcc is successful in
producing a Cygwin64 executable that Cygwin64 GDB can work with. This
combination of circumstances led me to wonder how stabs was chosen for
Cygwin64.

>
> I question your use of Cygwin instead of MinGW for your compiler but
> that is just a musing.
>

When I cobble together an I/O system for the language's runtime, I
will probably switch the project to Linux-only. I/O is one of the
interesting side issues I wish to tackle.

--
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

Defaulting to stabs debug output from AS Cygwin64

[Michael Enright]

I am working on a little compiler for fun, which generates assembly
code. At this point I manually invoke as and ld.

For debugging I added the -g option to the invocation of as, but then
ld failed with

 t.o:t.s:1:(.stab+0x14): relocation truncated to fit: R_X86_64_32
against `.text'

Looking into this on Stack Overflow I was taught that stabs is
obsolete. I think 'obsolete' may not be quite the right
interpretation, but 'wrong for Cygwin64' could be the right story.
Practically speaking, without thinking about it too critically,
-gdwarf2 in place of -g is the solution.

I'm trying to find authority for saying anything exact about the situation:
1) Is there a reason why stabs is the default for '-g' with Cygwin64?
1a) Is a patch desired to make dwarf2 the default?
2) Is there a way within Cygwin64 that a .o file with stabs can be
properly processed by ld to give proper input to gdb?
3) Is stabs fatally flawed for the purposes of Cygwin64 or could it be
upgraded, within the existing meaning of the stabs specification, so
that it would work?
3a) To put it another way, is this just a stabs bug that could be
fixed for Cygwin64?

Above when I say Cygwin64, I'm talking about straightforward native
use of as, ld, and gdb, not cross-compiling to some other platform.

--
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: Cygwin alongside WSL

[Michael Enright]

On Mon, Oct 23, 2017 at 5:38 AM, KARL BOTTS  wrote:
>
> Does anybody have any concrete experience using Windows Subsystem for Linux
> (hence WSL) on the same machine, alongside Cygwin?
>

Yes. I have. I assume you are soliciting some descriptions of people's
experience.

I have various projects which come from various git repos. I use
Eclipse CDT to edit these most of the time. This makes it a little
tricky to use WSL.

I use Cygwin, 64-bit version, when I have to do checkouts or pushes,
and I do this from a Cygwin mintty bash session. This puts my files in
a subdirectory of $HOME in Cygwin.

I use WSL to build and execute my programs. I generally would be using
a straight g++ command to build, or CMake. Eclipse, which we may think
of as an "ordinary Windows program" for this discussion, cannot access
files in the WSL filesystem without using unsupported tricks, so
that's why I don't keep my files under WSL's filesystem. On the other
hand, using WSL I have less differences with Debian. Since the
projects are not meant to support "all POSIX systems" or "Cygwin and
Linux", these things give me what I need.

Most of the time I don't run into differences between Cygwin and WSL,
because I don't go into the areas where they do differ. I have done a
few graphical projects but they output to raster files instead of the
screen.

The biggest problem in this is Eclipse, and indeed the complete lack
of a decent graphical IDE for WSL. This means that the most useable
configuration for Eclipse is to define the project as a Cygwin
project, which will have minor differences with Ubuntu. The two have
different schedules for updating the C++ compiler, CMake, and so on.
Also most IDEs default to cr-lf line separators when they run on
Windows. But at least Eclipse can be configured to newline separators.
Some IDE's do not allow themselves to be configured 'non-native'.

The Windows boxes in question are allowed to update themselves
overnight and I run the usual update commands on WSL itself. I haven't
found this update policy to interfere with my work so far.

--
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: Apache rebase trouble

[Michael Enright]

On Tue, May 23, 2017 at 3:59 PM, Michael Lemke wrote:
>
> Lacking further clues I did the trial and error thing and removed some
> stuff I thought I didn't need (like GNOME). Not sure yet what I broke but
> my Apache is working again.  Thanks for the hint that the number of known
> dlls could be a problem. I'd still appreciate more precise information
> of how rebase works and if there is a more systematic approach.
>

The command rebase -is gives a list of the DLLs, their sizes and where
they are based.
The DLL size is in "field 5" as 'sort' recons fields, so
rebase -is | sort -k5 will dump the DLLs in size order.
On my system the last DLL in the output is an LLVM DLL which I believe
is used by the X server. A lot of the top DLLs appear to be related to
the X server, some of those are code-generation DLLs for the LLVM JIT
to use. The footprint of the X server seems large.

I haven't updated Cygwin in some time so your results may differ.

--
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: reply: problem with nc 1.107-4

[Michael Enright]

On Wed, Mar 29, 2017 at 11:28 PM, 高锋 wrote:
> Two days ago,i wanted to determine whether a udp port of another machine is 
> open or not, which is deployed on different subnet.
> But windows platform does not provide utility that can dose this.So i 
> downloaded a setup.exe from cygwin,of which version is 2.877(64 bit),and i 
> had never use this utility before.

I tried this command on Debian 8.7. My conclusion is that this didn't
tell me that the UDP port is listened to by another machine. I used
your exact command, which had similarly uninformative results as
yours. There is no 10.31.x.x machine that I can reach, yet 'nc -u'
allowed me to send text to that address and port. Strace of 'nc -uz'
showed that the special -z option (zero i/o port scan) code "sent
successfully" a single byte to the destination, even though it doesn't
exist.

I conclude that "nc -uz" can't be used to determine unambiguously if a
UDP host is available, because it will succeed even if the host is not
present. And that carries to all systems that use the same 'nc'
utility as Debian or Cygwin.

--
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: problem with nc 1.107-4

[Michael Enright]

On Wed, Mar 29, 2017 at 7:24 PM, 高锋  wrote:
> I just installed the latest nc 1.107-4 on windows 7 platform.When lauched
> the command like:
> nc -vuz 10.31.28.188 6110
> ,each time it reported connecting successed,even if the target ip
> 10.31.28.188 does not really exists.
> Could someone tell what wrong with me?
>

It's possible that you are accustomed to using, or using a script
written for, the 'nc' command that was included in the 'netcat'
package, which was superceded in Cygwin some years ago. This could
have happened if you were using Cygwin 1.7 (I think) and then upgraded
to a brand new version of Cygwin. It is common, in my experience, that
someone would have installed an old version of Cygwin, used it for
years, and then upgraded to a new version.

Message from Vinschen about this change:
https://cygwin.com/ml/cygwin-announce/2012-05/msg00015.html

--
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: i686 ld couldn't resolve wglCreateContext from libopengl32.a on x86_64 system

[Michael Enright]

On Thu, Mar 2, 2017 at 5:19 PM, Yaakov Selkowitz wrote:
>
> Maybe, maybe not.  Mixing *NIX and Win32 APIs isn't so simple.
>

I have some small projects that do this mixing. A determined
individual can do it. I have not done it with 'wgl'

--
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: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 1:34 PM, Andrey Repin wrote:
> Greetings, Gluszczak, Glenn!
>
>> * is a legal character for ls but perhaps not cygpath?
>
> "*" is not a legal path name character. And cygpath expects a path.

AFAICT, '*' is a legal character in a filename or directory name on
Posix systems and Linux.
Source:
https://en.wikipedia.org/wiki/Filename#Reserved_characters_and_words

--
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: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 1:46 PM, Gluszczak, Glenn wrote:
> I suppose the glob explanation from Michael explains this behavior in sh.
> Though unsupported, it seems to work (probably some side cases do not).

It seems to me that the behavior is supported and working. Bash or sh
takes an unescaped argument /usr/bin/* and expands it to a list of
names, which it provides as an array of arguments to the called
program, cygpath in this case. Then cygpath converts each and outputs
each result. If the user escapes the argument in someway, the asterisk
survives and is treated as a Unix file name character. If there is no
glob expansion, in the case of the unescaped argument
/usr/nonexistent/* for example, Bash only passes one argument, and the
asterisk in that is treated as a filename character.

I think when the output to your terminal is weird, it is because of
locale settings or code pages that either hide or garble the output of
the unicode character. When the output is piped to od as Andre does,
the output is clearly the UTF8 byte sequence for U+F02A.

--
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: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 12:42 PM, Michael Enright wrote:
> On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote:
>> Sorry, I forgot the user I log in as is switching to cmd.exe.
>>
>> This doesn't happen in sh or tcsh, so it is probably a non-issue.
>>
>
> My results are from running a "normal" bash-under-mintty setup.
>
> If I go to a cmd.exe window and start bash,
>
Correction. I simply put c:/cygwin/bin on my path I didn't start bash.
[redfaced emoji]

> Z:\>cygpath -w "/usr/bin/*"
> C:\cygwin\bin\?
>
> Z:\>
>
The result when I really did go into bash was basically identical (the
character rendered as a question mark, which is the expected
rendering).

--
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: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 12:31 PM, Gluszczak, Glenn wrote:
> Sorry, I forgot the user I log in as is switching to cmd.exe.
>
> This doesn't happen in sh or tcsh, so it is probably a non-issue.
>

My results are from running a "normal" bash-under-mintty setup.

If I go to a cmd.exe window and start bash,

Z:\>cygpath -w "/usr/bin/*"
C:\cygwin\bin\?

Z:\>

This is consistent with the explanation that an asterisk ends up
having a private-use character substituted in for it.

--
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: cygpath

[Michael Enright]

On Fri, Feb 10, 2017 at 11:36 AM, Andrey Repin  wrote:
> Greetings, Gluszczak, Glenn!
>
>> Isn’t this a defect in cygpath?  Looks like memory corruption.
>
>> %%%cygpath -w /usr/non-existent/*
>> C:\cygwin\usr\non-existent\�[W��
>
> Looks more like private character space combined with incorrect terminal 
> setup.

The link to private character space is reay obscure. Firstly, the
commands that sometimes show failure have a '*' or splat in them. Bash
will try to convert a path with a splat in it to the list of matching
paths, if there are matches. If there aren't, then the argument seen
by the spawned program will contain a splat. Then the cygpath program
has to properly describe the path that contains the splat. The splat
is not a legal character IN A WINDOWS PATH, but a private character
could be and that's how terminal configuration enters in. Cygpath is
giving the string that would be used to represent the path, and that
string will contain a private use character.

In my testing, the environment has no LC variable set to anything, so
the locale mechanisms are presumably doing their default things. All
my attempts with this got a empty box character at first, if the
asterisk went through. That empty box character is presumably some
private use character that is supposed to substitute for an asterisk.
When I switched mintty's configuration to use Consolas, the
previously-run tests output was rerendered by mintty and the 'bad'
character rendered as a box with a question mark inside.

If I enter cygpath -w /usr/bin/* I get output consisting of all the
files in /usr/bin with their paths converted to Windows form. If I
escape the argument so globbing is not done, I get the strange output.

 cygpath -w '/usr/bin/*'
C:\cygwin\bin\

In the above the ticks around the path prevented the path from being
globbed. It might be considered unexpected though, that the path with
an asterisk would be treated as "The user desired to know what the
windows path to a file would be if it's cygwin path ended with an
asterisk". I think the odds of that user story are vanishingly small
compared to the odds of "What would a Windows path to a wildcard look
like that corresponds to this Cygwin wildcard?" But that's a design
problem.

--
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: Hangs on connect to UNIX socket being listened on in the same process (was: Cygwin hanging in pselect)

[Michael Enright]

On Thu, Jan 12, 2017 at 2:13 PM, Corinna Vinschen
 wrote:
> Step 3:
>
>   If we did it really intelligent, maybe we finally also have a method
>   to implement descriptor passing.  Finally.  After all these years.
>
> And maybe, we should not actually use the socket itself to exchange
> the information but rather create some kind of side-channle for that.
>
> Especially in terms of step 3, I'm mulling over this for years now
> and always something else got in the way and had to be done first.
>
>

I made a program that needed to pass windows HANDLEs between processes
and so that receiving process could access the shared memory
represented by the HANDLEs. I was emulating facilities many programs
implement using send_msg, but I was using Windows (named?) pipes. It
felt a lot like what you need for send_msg, and it required newer
Windows APIs. So by doing the crazy thing of completely rewriting your
AF_UNIX sockets you could "easily" add descriptor passing.

--
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] Updated: Cygwin 2.6.1-1

[Michael Enright]

On Mon, Jan 9, 2017 at 4:39 PM, Steven Penny  wrote:
> It looks like fixing this may have caused another issue. Example test:
>
> With cmd.exe, you can type Alt 234 and it produces
> GREEK CAPITAL LETTER OMEGA U+03A9. However with Cygwin via Cygwin.bat it 
> yields
> nothing. Non ASCII characters can be read from scripts, but they cannot be
> entered interactively.
>
> They cannot be pasted either; pasting some words will remove all non ASCII
> characters.
>

My cygwin 32-bit install has not been updated for a while. When I do
ALT234 with numeric pad keys and numlock on, from bash directly
running under cmd.exe, I get :\251 at first (colon backslash 251) and
then when I hit enter for the command, I get a beep.
If I do the ALT234 with numeric pad and numlock in CMD.exe I do get
what looks like a capital omega. So a months old bash does not respond
well to this ALT numpad stuff.

My information supports the judgement that weird behavior in this area
was introduced a while ago.

For comparison only, If I do ALT234 with mintty running bash, I get
neither the :\251 nor capital omega, I get lower case e with
circumflex.


>c:\cygwin\bin\bash --version
GNU bash, version 4.3.42(4)-release (i686-pc-cygwin)

--
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: Mintty 2.4.0 and Deja Vu Sans Mono 2.35: issue with bold

[Michael Enright]

On Tue, Jul 12, 2016 at 12:26 PM, Thomas Wolff wrote:
>
> Mintty generates "faux-bold" by overstriking with a pixel offset of 1. Maybe
> it should scale the thickness with the font size (like it does now for
> manual underline and VT100 line drawing graphics), at increased risk of
> clipping, however.
>
> Suggestions welcome.
> Thomas
>

I assume you have already tried quite a few suggestions. Did you try
digitally inflating the bitmap image of the normal weight characters?
Did you try using the metrics from the normal weight while rendering
with the bold weight?

--
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: pass arguments enclosed with double quotes from bash shell to windows program

[Michael Enright]

On Sat, Apr 2, 2016 at 11:59 AM, Cary Lewis wrote:
> I need to start acrobat from a bash shell.
>
> Acrobat needs some of its parameters to be enclosed with double
> quotes. This is needed to automatically open and print a pdf.
>
>
> If I try to do a \", then it passes the \" to the windows app.

I frequently use WinMerge, a graphical text file comparision program,
from the bash shell. Occasionally this involves a file in the current
directory vs a file at the end of a path full of spaces and slashes.
If this question had come up yesterday I could have looked at my
history for examples. My recollection is that the rules for expanding
arguments enclosed in single quotes are helpful. Single-quoted
arguments are processed much less by bash than even double-quoted
arguments. A simple example is if you need to put a backslash in an
environment variable, you don't have as many layers to fight if you
use single quotes export regex='search\$'. I also use $(cygpath) in
some fashion to convert the path since WinMerge is not a Cygwin
program. I get the full path to one of the files using tab completion,
and then I modify the path by surrounding it with the necessary
cygpath syntax to convert the path to a Windows path.

--
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: ctrl-c doesn't reliably kill ping

[Michael Enright]

On Wed, Mar 16, 2016 at 7:51 AM, cyg Simple wrote:
>
> My ISP for my connection to the WWW is the one that is doing the
> inappropriate redirects.  I sometime get these even when using VPN to my
> employer's intranet.  My ISP also provides phone and TV Cable and I'm
> guessing that the accepted practiced exception is practiced by all such
> companies.
>

Can confirm. Readers may be interested to learn that I tried to set
the DNS manually in the connection properties of my VPN connection (to
the exact same thing the VPN connection would have configured anyway)
but this did not work either. I used my ISP's opt-out page and that
didn't help. I also learned how to empty DNS caches in Windows
(ipconfig /flushdns) and Google Chrome (chrome://net-internals/#dns)
and none of those measures was effective. I couldn't use the wiki with
its IP address because the links apparently are full paths and there's
redirects involved (with full paths) and every complete URL goes to
name resolution. It was as if  (that means I'm speculating here) as if
using the standard DNS port was causing the ISP to DPI my DNS
requests. Or maybe they are just looking in all the packets. Could the
revenue from those bogus links be so high???

--
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: stampy error running Make after installing update 2.4.1.1 to Cygwin64

[Michael Enright]

On Tue, Jan 26, 2016 at 11:10 PM, Robert May  wrote:
>
> I still can.t make sense of it
> below is the contents of makefile
>
> the end of running make is still the same
> $ make
> makefile:1: *** missing separator.  Stop.
>

I didn't get that line but I got several others. I extracted a
makefile from the email starting from AFTER the 'm' and ending at the
endif that occurs in the buildall target.

Each line that I got an error from was a line that was indented with
spaces (perhaps due to email) and when I changed that to a tab or two
the 'next error to fix' changed to something else. It ended at "No
rule to make target build-stampy" but I don't have any of the files so
that's probably the end of my assistance.

--
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: Taking a very long time to run /etc/postinstall/texlive-dollection-context.sh

[Michael Enright]

On Mon, Jan 18, 2016 at 1:06 PM, Kenneth Wolcott  wrote:
>
> 
>
>   Sometimes I wish that TexLive could be its own group in Cygwin as
> there are times that I'd like to pick most of what is in the Text
> Cygwin group without TexLive and sometimes I'd like to just pick
> TexLive..  Other times I'd just skip the Text Cygwin group completely.
>
>   In this case I really don't need TexLive but I like to have several
> other of the packages that are in the Text Cygwin group.
>
>

I have TexLive in at least one of my Cygwin setups even though I
didn't request it. Something else depends on it.

Why do you select the entire "Text" group? I would guess that the
reason is, your usage is different from mine. I don't select by
groups, I try to pick the things I need and they drag in the things
that they think they need. Have you ever tried to just pick the things
you want and let setup pick the things they need?

I think TexLive snuck in on me by this means. It's possible that even
if you took a "surgical" approach to the Text group you'd end up with
TexLive anyway.

--
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 incorrect System path from cygpath with case-sensitivity enabled

[Michael Enright]

On Fri, Jan 1, 2016 at 1:21 PM, Bryan Henry wrote:
>
> [~]$ cygpath -S -u
> /C/WINDOWS/System32
> [~]$ file `cygpath -S -u`
> /C/WINDOWS/System32: cannot open `/C/WINDOWS/System32' (No such file or 
> directory)
> [~]$ file /C/Windows/System32
> /C/Windows/System32: directory
>

Although I haven't enabled case-sensitivity I noticed the following:

In power shell, the value of $env.Path is reported with windows
directories where the windows directory is given all in lower case.
But in the same shell, the name of the Windows directory given by "ls
\" is spelled "Windows". I find that to most likely be the spelling of
the directory entry because "ls" seems to faithfully report directory
names in the case given by whatever created the directory in the first
place, instead of some affectation of "ls" capitalizing things.

In Cygwin,
$ cygpath -S -u
/cygdrive/c/windows/System32

I'm running Win10/64 and 64-bit cygwin.

--
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: CTRL-C does not work in Cygwin when using pipes

[Michael Enright]

On Tue, Dec 29, 2015 at 2:57 PM, Michael Enright <m...@kmcardiff.com> wrote:
> And since I have chosen to participate in this thread, I tried the
> command in question. The success of my attempt does not mean that I
> don't believe there's a problem. My setup is Windows 7/64 in a VM,
> running 32-bit cygwin, mintty terminal and bash.

Also Windows 10 (not yet updated to November update) 64-bit running
64-bit Cygwin, minty and bash was okay.
Also, for fun, I tried this in Power Shell
> $env:Path += ";C:\cygwin64\bin"
> bash
$ perl -e 'while(1) {sleep 1;}

I was able to control-C out of this.

(And now we all know the way to augment the path in Power Shell!)

Not a recommended way to use Cygwin tools but I thought it was worth adding.

--
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: CTRL-C does not work in Cygwin when using pipes

[Michael Enright]

On Wed, Dec 30, 2015 at 1:03 AM, Michael Enright  wrote:
> On Tue, Dec 29, 2015 at 2:57 PM, Michael Enright  wrote:
>> And since I have chosen to participate in this thread, I tried the
>> command in question. The success of my attempt does not mean that I
>> don't believe there's a problem. My setup is Windows 7/64 in a VM,
>> running 32-bit cygwin, mintty terminal and bash.
>
> Also Windows 10 (not yet updated to November update) 64-bit running
> 64-bit Cygwin, minty and bash was okay.
> Also, for fun, I tried this in Power Shell
>> $env:Path += ";C:\cygwin64\bin"
>> bash
> $ perl -e 'while(1) {sleep 1;}
>
> I was able to control-C out of this.
>
> (And now we all know the way to augment the path in Power Shell!)
>
> Not a recommended way to use Cygwin tools but I thought it was worth adding.

Okay on review the above is not faithful to the problem statement and
so I tried some variations:
In bash inside Power Shell,
 echo foo | perl -e 'while(1) {sleep 1;}'
Will hang.

The same command pipeline, under the condition of having the path
augmented as above, will perform as expected and control-C will stop
the program.

--
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: CTRL-C does not work in Cygwin when using pipes

[Michael Enright]

On Tue, Dec 29, 2015 at 2:31 PM, Bill Smith wrote:
> Yes, I'm trying to do this with the standard shell, bash.  We have tried 
> using mintty or the xterm version but there were other issues.

The above implies something but I'm not sure what it is. Can you give
more detail?

mintty and xterm are terminal emulators which can't do much without a
shell inside them.
bash is among the valid shells you can use in mintty or xterm or rxvt.

The default "Cygwin terminal" icon if you set up a minimal Cygwin
installation is mintty serving as a terminal for bash.

So when you say you are trying with the standard shell I'm with you up
to the part where you say, "We have tried using mintty...but there
were other issues" because I use those together.

And since I have chosen to participate in this thread, I tried the
command in question. The success of my attempt does not mean that I
don't believe there's a problem. My setup is Windows 7/64 in a VM,
running 32-bit cygwin, mintty terminal and bash.

--
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: cmp (or echo) bug?

[Michael Enright]

On Mon, Dec 28, 2015 at 9:08 AM, David Balažic wrote:
> I tried it in zsh (32 bit cygwin) and there it works correctly:
>
> $  cmp  <(echo echo1)  <(echo echo2)
> /tmp/zshirbIJ1 /tmp/zshDsdZep differ: byte 5, line 1
>
> So it seems the bug is in bash.
>
A different conclusion is also supportable: That the two pipe
mechanisms have different edge-case behavior, resulting in different
outcomes for the command depending on which pipe type is used..

I tried this on 32-bit cygwin, Windows 7/64:
$ cmp <(for i in 1 2 3 4 5; do echo echo$i; done) <(for i in 1 2 3 4
6; do echo echo$i; done)
/dev/fd/63 /dev/fd/62 differ: byte 29, line 5

Your output from zsh shows named pipes are in use. "man zshexpn" says
that zsh can use anonymous pipes, yet it chose not to in your case. In
my case bash chose to use anonymous pipes, even though "man bash" says
it may use named pipes.

The man pages for these shells describe essentially the same syntax
and mechanisms for this process substitution mechanism. What is not
defined:
1) How do commands such as my for loop command or your simple echo
command provide output properly so that EOF isn't detected spuriously
2) How do programs such as cmp or diff read from their input in such a
way that they are not fooled by a file status that might appear to be
EOF but isn't.
3) Crystalline clarity as to when the shell prefers one pipe type to
another, at least not to this reader, and not that it matters.

--
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: Functional Cygwin GTK with native win32 backend

[Michael Enright]

On Sun, Dec 27, 2015 at 11:11 AM, David Xu  wrote:
> Hi!
>
> I compiled GTK with the native win32 backend, and it is functional.
> Brief demo: http://i.imgur.com/PAWyLdW.gif

Many programs that originally target Linux have been made available to
Windows users by means of packaging them with GTK et al. It's not too
surprising that this would work.

>
> I would like to bring up discussion about the possibility of including
> a native windows build of GTK in the Cygwin package list as well,
> since it turns out that the steps that I took weren't so bad.

GTK is already available through Cygwin with the X backend and the
PTBs[0] here like it that way.

--
[0] Powers That Be.

--
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: xterm 320-1 won't start with XTerm*faceName set in .Xresources

[Michael Enright]

On Mon, Nov 9, 2015 at 12:03 PM, Marco Atzeri  wrote:
> On 09/11/2015 20:17, Brian Neu wrote:
>> fc-list outputs nothing.
>
>
> this is strange
>
> Is it functional ?
>
> $ /usr/bin/fc-list --version
> fontconfig version 2.11.1
>
>
>
Would setting the environment variable FC_DEBUG=4095 (or some other
value) be of any use?

The output of fc-list is empty on this one particular Cygwin setup
here, but with FC_DEBUG I get:
$ FC_DEBUG=4095 fc-list | head
FC_DEBUG=4095
Loading config file /etc/fonts/fonts.conf
Add Subst match
[test]
pattern any family Equal "mono"
[edit]
Edit family Assign "monospace";

Add Subst match
[test]

FC_DEBUG is documented at
http://www.freedesktop.org/software/fontconfig/fontconfig-user.html
(first match for FC_DEBUG) but it consists of bits for features and
4095 turns on 12 of them. 128 might be the most important value.

--
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] putty 0.65-2

[Michael Enright]

On Mon, Nov 9, 2015 at 4:28 PM, Yaakov Selkowitz wrote:
> The following packages have been uploaded to the Cygwin distribution:
>
> * putty-0.65-2
>

I have the "Unix" version of this on a Linux box, which I built from
source. I also have the "normal" Windows version. Which of these would
you say the Cygwin package is closest to?

I like putty much better than minicom on Linux for serial ports, but
the Windows version allows editting the ANSI terminal colors on the
fly and the Unix version doesn't. The Windows version has a context
menu for restarting the same connection and other things, which the
Unix version doesn't. These deficits don't keep me from preferring to
use putty on Linux over the various alternatives.

--
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: problems with to_string not declared in this scope

[Michael Enright]

On Sat, Oct 24, 2015 at 10:31 PM, JonY  wrote:
>
> On 10/25/2015 01:00, Michael Enright wrote:
> >
> > I sometimes wonder what would be involved in fixing this.
> >
>
> Full C99 *printf support. Corinna answered on the same thread
> https://sourceware.org/ml/cygwin/2015-01/msg00245.html
>

Yes, but what I was wondering about was the first couple of levels of
detail below that, i.e. which algorithms, having yet to be coded in
newlib, are needed to enable long double textification in newlib? I
know practical methods for textifying integers but as far as I know
floats are harder. Maybe I could use the parable of the stone soup and
get the work rolling by offering a filename? ldtostr.c

--
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: problems with to_string not declared in this scope

[Michael Enright]

On Fri, Oct 23, 2015 at 9:28 PM, Luong Hoang wrote:
> The error says 'to_string' was not declared in this scope

Lack of developer attention in the related project newlib. I googled
this myself a couple of weeks ago. Apparently if you start to work on
that you pull in a lot of other little missing tasks including
actually writing the string conversion piece for some of the wider
scalar types.

https://sourceware.org/ml/cygwin/2015-01/msg00049.html is near the
message you reference but I couldn't tell if it was the same thread.

I sometimes wonder what would be involved in fixing this.

--
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: Cygwin/X installation: Unable to extract /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

[Michael Enright]

On Tue, Oct 6, 2015 at 11:10 AM, Jon Turney  wrote:
>
> But there is no need to guess about this, it's documented in the fontpath.d
> section of the Xserver man page [1]
>
> [1] http://x.cygwin.com/docs/man1/Xserver.1.html#lbAN
>

I still have questions.

Good old setup_x86 fortuitously gave me the chance to see an error
message involving one of these symlinks. I reviewed the setup log and
read that apparently such a symlink was created as follows:
io_stream:mklink
(cygfile:///etc/X11/fontpath.d/xorg-x11-75dpi:unscaled:pri=20 ->
cygfile:///usr/share/X11/fonts/75dpi)
But there is no /etc/X11/fontpath.d directory on the system.

The man page doesn't say in explicit procedural terms what the end
user has to do to make fontpath.d exist and it doesn't seem to get
created by setup. There are three occurances of fontpath.d on that
page and none of them say where you should put it.

Could we change it to be more tutorial, something like:
If you wanted to modify the priority of the bitmap fonts for example,
you could go to /etc/X11 and create fontpath.d and then here are some
ln commands:
ln -s /usr/share/X11/fonts/75dpi xorg-x11-75dpi:unscaled:pri=20
...

--
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: Cygwin/X installation: Unable to extract /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

[Michael Enright]

On Tue, Oct 6, 2015 at 7:42 AM, kuaf  wrote:
> Unable to extract
> /etc/X11/fontpath.d/xorg-x11-fonts-75dpi:unscaled:pri=20

Something tells me that this error message is not only giving a file
name, it is giving some font parameters that had been specified
directly or indirectly by the application. The colons divide the
string into parameters and the first one is a file or directory.

--
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: [Cygwin-ports-general] Ncview

[Michael Enright]

On Thu, Oct 1, 2015 at 10:35 AM, Yaakov Selkowitz  wrote:
>
> Confirmed.  Often 64-bit-only issues come down to one or more of the
> following:
>
> * implicit function declarations.  Per the C standard, argument types
> are assumed to match whatever is given (which may be wrong if e.g. 0 is
> used instead of 0L or (PointerType)0 or NULL etc.) and the return type
> is assumed to be int (which will truncate the actual return value when
> it is actually a long/pointer).
>
> * vararg types.  Because these types aren't declared, the compiler can't
> automatically cast values to the correct type, so literal values and
> symbolic constants must be explicitly cast if they are not meant to be
> an int and are not obviously a long/pointer.
>

Good list. I would also add attempting to store pointer differences in
an "int" instead of ptrdiff_t and the issue you can see from
https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models,
which is that the integer types other than long long on 64-bit Windows
are 32-bits while on 64-bit Linux 'long' and 'long long' are both
64-bit. This issue means that 'long' is a good-enough hack for
ptrdiff_t on 64-bit Linux but not 64-bit Windows. Does Cygwin differ
from Windows itself on this issue? Most 32-bit-designed code is
probably more sensitive to the pointer-difference aspect of this.

--
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: Building cross toolchain on cygwin from source

[Michael Enright]

On Tue, Sep 29, 2015 at 10:06 PM, Hari Narasimhan H.N  wrote:
>
> I am using a crosstool-NG system. During configuration of GMP it
> throws the following error
>
> "could not find a working compiler"
>
> whereas I have gcc4.9.3 installed and working.

You should be able to tell from config.log what GMP's configure tried
to use as the compiler. GCC is capable of being compiled with an old
compiler and that applies equally to creating a native compiler or a
cross compiler.

My best guess is that this problem is not a Cygwin problem. I have had
that same error message from configure scripts run under Linux,
attempting to cross-compile various open-source libraries, and it
comes down to some over-looked detail in the configure arguments that
impact how the script finds the compiler to use. Possibly a good
question for Stack Overflow.

--
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: Building cross toolchain on cygwin from source

[Michael Enright]

On Tue, Sep 29, 2015 at 5:20 AM, Hari Narasimhan H.N wrote:
>
> We have a requirement to build a GCC cross toolchain for Xtensa
> architecture for a cygwin host from source. So far we have not been
> successful building even a native toolchain.
>
> Please let us know if such a thing is supported on cygwin or workarounds if 
> any.
>

I have done this for ARM with no difficulty. It did not appear any
different from doing the task on Linux. So what were the problems you
ran into?

--
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 old win32 api

[Michael Enright]

On Tue, Sep 22, 2015 at 10:54 AM, Yaakov Selkowitz  wrote:
>
> Installing with Cygwin Setup.
>
>
> This is the only supported installation method.
>

On Tue, Sep 22, 2015 at 10:59 AM, David Stacey wrote:
> We're drifting off topic, but never mind...

Thanks Yaakov, David, Achim, Vince and whoever else may be moved to
chime in.  I don't wish to take over the list with this subject. The
answers so far have given me much to think about, and are complete
enough that I don't need to ask follow-up questions at this time.

--
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 old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 9:16 PM, Vince Rice  wrote:
>
> The blindness was, as I’ve already pointed out, caused by blindly
> updating software

No one was "updating"! I have diagnosed what I did "wrong" before and
I am satisfied with my conclusion. I don't yet know of a way to keep
changes from affecting me, but I know some things I can do to be
prepared for the changes that might happen, so I'm doing those things.

No one was updating. New workers needed new Windows boxes with Cygwin
on them. What is the process for putting Cygwin on a new Windows box?
It isn't "rsync Cygwin from IT".

Cygwin's default (or only) distribution method has a role to play in
this. Does anyone ever setup Cygwin on a new Windows install other
than by downloading setup_x86.exe or setup_x86-64.exe and working from
there? Is any such alternative given equal priority on cygwin.com ?

I am interested to hear if anyone has managed a group of Cygwin users
and the configuration they use, and how they went about it.

More out there, I'm interested in thoughts about making it possible to
tell a group such as a customer base (a group of autonomous,
free-will-possessing individual organizations) how to setup Cygwin so
a non-Cygwin component can be added on top and work even though it
might not still work with a regular default fresh Cygwin.

--
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 old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 1:31 PM, Marco Atzeri  wrote:
>
> the change in nc had nothing to do with cygwin
> change between 1.5 and 1.7
>
> https://sourceware.org/ml/cygwin-announce/2012-05/msg00015.html
>

Implying a tie between the nc version to the release of 1.7.0-0 was
wrong on my part. I am not wrong in this change to 'nc' did happen.
Because I was not tracking all things Cygwin all the time I didn't
know about it at first, and the people who had problems with it in my
world were those who had deployed new workstations with Cygwin 1.7
while those who could just keep using Cygwin 1.5 did not have
problems. The point is that Cygwin doesn't stay the same all the time
in the ways that all users may care about.

--
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 old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 5:50 PM, Vince Rice  wrote:

>blindly

The blindness was blindness to the fact that new users were getting a
different version than existing users in some way other than fixing
vulns. Since Cygwin isn't the sort of product that needs to make up
sham reasons to upgrade as Microsoft Word does ("Look! A Ribbon!"),
one assumes that constant incorporation of upstreams, constantly
switching away from unmaintained upstreams to maintained-but-different
upstreams etc is what the Cygwin user base wants. Or at least most of
it.

Do Cygwin'ers ever debate or think about an LTS track for Cygwin? Is
that why there's a "time machine?"

--
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 old win32 api

[Michael Enright]

On Mon, Sep 21, 2015 at 12:25 PM, Andrey Repin  wrote:
> Greetings, jacob.a.lamber...@l-3com.com!
>
> 1. https://cygwin.com/acronyms/#TOFU pretty please.
>
>> Upgrading would be a pain,
>
> Who said that?...
>
>

PMFJI,

Between Cyg 1.5 and 1.7 the command-line interface changed on the "nc"
utility and, from the point of view of someone who at the time did not
read this list, it was a silent, breaking change. So I would not be
surprised if OP had a situation where recompiling an old version was
best.

--
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: Requesting ISL update

[Michael Enright]

On Tue, Sep 15, 2015 at 3:03 AM, JonY wrote:
>
> Hi Achim,
>
> Can you please update ISL for newer versions of GCC?
> http://isl.gforge.inria.fr/ says 0.15 is the latest.
>

PMFJI,

I was setting up a cross compiler this past Sunday under Cygwin, using
GCC 5.1.0. I followed the "BYOI" (Bring your own Infrastructure) path
and ISL 0.15 was my first choice (being the latest), but did not work.
ISL 0.12.2 did work. ISL 15 passes the initial "compatible version of
ISL" check that the GCC configure script does, but the granite code
within GCC doesn't actually compile properly. When I recompiled
without the --with-isl setting in configure, no ISL library was found,
according to the "compatible version of ISL" message again, and the
compiler was a success anyway. I built an OS with it, threw it away
and started over using ISL 0.12.2. Everything worked, and the
resulting OS build (Embedded Xinu for RPi) ran properly.

--
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: "permission denied" issues when removing files/folders created by cygwin

[Michael Enright]

On Tue, Sep 1, 2015 at 12:48 PM, Roger Pack  wrote:
> It appears the problem lies with creating a file named "NUL" windows
> utilities just don't know how to deal with it (you can recreate it by
> creating a folder, then from cygwin bash $ touch NUL) then try and
> remove the folder with windows explorer.

The utilities "know" how to deal with it, given their design:
http://blogs.msdn.com/b/oldnewthing/archive/2003/10/22/55388.aspx

--
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: how to detect whether a laptop is docked

[Michael Enright]

On Wed, Aug 26, 2015 at 12:50 PM, Yaakov Selkowitz wrote:
 On Wed, 2015-08-26 at 19:27 +, Nellis, Kenneth wrote:
 I am looking for a method by which I can determine within a shell script
 whether my laptop is docked or not. Google provided some answers for Linux
 and Windows users, but the several ways I tried did not work out.

 One Windows solution * provided a VB script that accessed a registry 
 variable ‡,
 but my registry value remains the same whether or not I'm docked.

 The Linux solutions required either a file I don't have (/var/run/stab) or a 
 tool
 that I don't have and couldn't find in a Cygwin search (acpid or lsusb).


If you cat the path to the registry key it doesn't show anything but
if you hexdump it there is a '1' (in my case, 2 out of 2 systems)
stored as a DWORD I suppose. I think that value is wrong for at least
one of those (a docked laptop or a VM in a PC). I got the impression
the feature is not 100% solid.

--
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: js185 package problem (was Re: Seg Fault in strftime)

[Michael Enright]

On Mon, Aug 24, 2015 at 10:39 AM, Yaakov Selkowitz  wrote:
 On Mon, 2015-08-17 at 10:10 +0200, Corinna Vinschen wrote:
 Maybe the package just needs rebuilding.  Yaakov?

 I have uploaded js185-1.0.0-4.  Please let me know if that helps.

 --
 Yaakov


Good news.
The upload propagated to my favorite mirror, I tried out my
application and it worked.

Thanks, everyone.

At one point I checked the box for the source to this library, and
looked at the tarball. I saw that there were patches (minor if I
recall correctly) and I wondered if I'd be able to reproduce the build
accurately from the tarball and those patches. Is there a generic
reference for how packages are built to ship in Cygwin, or is this an
ad hoc thing with different steps for different packages?

-- 
mte

--
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: setup-x86_64.exe Unable to get setup.ini on all mirrors

[Michael Enright]

On Mon, Aug 24, 2015 at 10:46 AM, Dennis Putnam wrote:
 On 8/24/2015 1:42 PM, Achim Gratz wrote:
 Dennis Putnam writes:
  Again keeping in mind
 that my browser has no trouble finding URLs, I tried 'nslookup' from a
 command prompt and it can find nothing. The error is no response from
 server. This happens with all the name servers I tried. It makes no
 sense the the browser can find IPs but 'nslookup' cannot.
 It would make sense if it was using a proxy.  So what happens if you
 tell setup to use the IE proxy settings?
 There is no proxy. This was working for a couple of years with no
 problem. It was not until that Lavasoft Malware was installed that this
 all started.

From what I could learn about the products of that company in 5
minutes, the symptoms you report make sense if the software you
thought you had removed remains installed. My guess is the software
concerns itself with maintaining connectivity (and of course doing the
things that are classified as malware) as long as the connectivity is
done through a browser, or other things whitelisted by the software.
Since nslookup and setup-x86_64 are not the browser, the software
blocks them. The software is not interested in things that enable you
to do non-browser things. Have you rescanned your system? Which
software is still using the internet successfully?

--
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: Seg Fault in strftime

[Michael Enright]

On Wed, Aug 5, 2015 at 1:02 AM, Corinna Vinschen  wrote:
 On Aug  3 23:33, Michael Enright wrote:
 On Mon, Aug 3, 2015 at 9:52 AM, Michael Enright wrote:
  I'm interested in a solution at the libmozjs level

 Is there anything I can do to advance a solution in libmozjs?

 You could report the problem upstream, ideally.  Since the behaviour
 is not restricted to Cygwin (at least glibc and OpenBSD both use the
 same way to handle tm_zone/tm_gmtoff in strftime), they should be
 interested in a fix.

Looking at the upstream source it seems that they (mozilla.org) have
done something to allow their configure script to detect tm_zone's
presence. If the related configure variable HAVE_TM_ZONE_TM_GMTOFF is
defined as a result of configure's testing, then some code is enabled
that has the goal of getting those fields populated in the struct tm
that is passed to strftime. The steps are to transfer values from the
pseudo-tm struct they use to a temporary struct tm, call mktime with
that to get a time_t, pass the time_t to localtime_r, and then use the
resulting tm_zone and tm_gmtoffset values in the struct tm that they
pass to strftime. To me this all means that mozilla.org has the proper
code available and machinery to activate it.

I think the only reason there's a crash is because this mozilla.org
code is not enabled in cygwin's libmozjs185 for some reason.

I cloned the git repo that mozilla.org makes available and ran the
configure script. I was not able to build from the resulting setup,
but I was able to confirm that the HAVE_TM_ZONE_TM_GMTOFF macro is
defined. So the mozilla.org configure script does detect the members
on current Cygwin headers. Since that is the case the next step is to
look specifically at how libmozjs185 is built for distribution within
Cygwin.

Is there a possibility that the maintainer of Cygwin's library uses
hand-modified configure output to get around some problem, and that
stuff needs to be tweaked?

--
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: Seg Fault in strftime

[Michael Enright]

On Mon, Aug 3, 2015 at 6:42 AM, Corinna Vinschen  wrote:
 Hang on.  So you suggest that Glibc, Cygwin, as well as any other
 implementation based on the localtime.c code from Arthur David Olson,
 stop using the additional struct members?  Despite them doing the right
 thing where the POSIX implementation is lacking?  Because there's one
 lib you need which doesn't work as expected, rather than rebuilding it
 with a matching fix?  That doesn't sound overly convincing to me.

It's not just one library that I use that has tripped over this. My
brief research into workarounds led me to the glibc guys shrugging off
another project's report. I bet there has been plenty of time spent on
this on the application side that has not left a trail for me to find.


 Other than that, you didn't answer the question:  How is a library
 supposed to know that the non-NULL pointer value is just garbage?

I think that is the wrong question. The problem is when there is
nothing telling anyone anything until something crashes. There is
nothing in the official documentation of the API to inform a user that
they must prepare the struct any particular way. There are two ways
the library would not find itself crashing from structs it didn't
like: Not use undocumented members that are pointers that can be
garbage, **OR** tell everyone how to initialize the structs, through
the POSIX spec or through man pages.


 I'm firmly with the GLibc guys here...


As far as I can tell the Glibc guys did not solve anyone's problem.
I'm interested in a solution at the libmozjs level and I'm interested
in getting struct tm in line with its documentation one way or the
other.

--
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: Seg Fault in strftime

[Michael Enright]

On Mon, Aug 3, 2015 at 9:52 AM, Michael Enright wrote:
 I'm interested in a solution at the libmozjs level

Is there anything I can do to advance a solution in libmozjs?

--
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: Seg Fault in strftime

[Michael Enright]

On Mon, Aug 3, 2015 at 1:36 AM, Corinna Vinschen wrote:

 The core thingy in POSIX is The time.h header shall declare the tm
 structure, which shall include at least the following members:


I saw this language myself.


 A conforming application does not use such a structure which isn't
 *at least* initialized to all 0 (memset).


I did NOT see any language that said anything about doing that. In any
case, the code I'm using is in another Cygwin package, libmozjs185.


 If your executable has been built prior to releasing this new code,
 Cygwin won't require tm_zone and tm_gmtoff anyway.

I have no idea how to interpret has been build prior in this case.

  However, for later
 built executables it will, and then there's no way around the crash
 if tm_zone is uninitialized.  If it's NULL, you'll get the current
 timezone.  But if it's not NULL it's suppsoed to be a pointer to
 a valid string.  How is a library supposed to know that the pointer
 value is just garbage?

In the case where the spec does not say anything except the members
shall include at least so-and-so, the library probably ought not to
assume that it gets its implementation-defined members defined as
inputs.

In the case where the POSIX spec uses at least language to define
visiible members AND specifically says that code layering on top of
that struct has to use memset or some other specific means to control
the unknown implementation-defined members, then of course the
implementation can assume that such things were done.

So the reason I'm twisting in the wind is because the implementation
has chosen to depend on the state of implementation-defined members,
the spec doesn't say anything about requiring applications to control
their values, and a library in Cygwin did not control their values,
and my application cannot work around it.

Also as an experiment I've tried to build v8. This has lead to the
subject of a new thread.

--
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

wspiapi.h uses _N conflicting with ctype.h

[Michael Enright]

Here's a reduction of a problem I had compiling v8:

#include ctype.h
#include wspiapi.h
char array[5];
__wspiapi_countof_helper(array);

The reduction isn't realistic but the problem is real.

On one hand, ctype.h uses _N and it is within its rights to do so as
ctype.h is part of the standard library. The statement that uses _N
initially is #define _N 04, so _N enters the global space of defined
macros.

On the other hand the template __wspiapi_countof_helper uses _N as the
name of one of its parameters. This usage is in the domain of strings
that can be interpreted as references to macros by the preprocessor,
so the _N gets interpreted by the post-preprocessor phases as 04,
causing some distress.

So... the win32 headers are free to use
leading-underscore-capital-letter symbols or no?

Anyway, how can this be addressed?

--
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: Seg Fault in strftime

[Michael Enright]

Brian,
In reference to your comments below I found this link to a repo of
SpiderMonkey source code.

http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp
And the function that calls strftime specifically:
http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp#l586

On Sat, Aug 1, 2015 at 2:47 PM, Brian Inglis  wrote:

 Two problems I have encountered in the past with manually constructed struct 
 tm:
 - failing to set struct tm.tm_isdst member to -1, or any negative value, so
 that mktime(3) will determine whether DST is in effect, and set the struct
 tm.tzname array from the tzdb

The code calls strftime after setting tm_isdst from its own struct's
corresponding flag.

 - failing to call mktime(3) for each struct tm variable to normalize the
 struct tm members, determine if DST is in effect if struct tm.tm_isdst
 member is -1, and set the struct tm.tzname array from the tzdb.
 Check back in the code to see if struct tm.tm_isdst is set and to what
 value, and if mktime(3) is called on each struct tm after it is filled.

The code doesn't call mktime at all.

 - failing to call mktime()


See above.

There is a section of the code that I believe is meant to be
configured in but it is not. This code calls localtime_r with a time_t
of zero and copies the resulting tm_gmtoff and tm_zone into the struct
tm that the routine will call strftime on. This code starts at line
621, 
http://hg.mozilla.org/releases/mozilla-1.9.1/file/920bcf17a9e1/js/src/prmjtime.cpp#l621
to jump to that line.

The things you advocate doing are super-responsible things to do. I
have a huge investment in using this particular library and now I'm
twisting in the wind because someone else appears not to have done all
the super responsible things they should have done.

I have found there is tons of code out there manually filling in
struct tm's and then filing bugs in glibc (not just newlib problem)
when things go wrong. And then without even the courtesy of a citation
of a spec these bugs are resolved WONTFIX because these upstreams
believe they have the right to insist that struct tm's should NEVER
manually be filled in and why would you do it anyway. I think the
minimum struct members specified on POSIX should be considered the API
to any function that reads struct tm, not because POSIX says so but
because it is the way to keep machines from getting pwned through
crash bugs.

I originally did my project with a bespoke build of SpiderMonkey
because libmozjs didn't exist on any platform (it also can be found
for Debian which is convenient for me and my some-day customers) but
maintaining a library when it's available prebuilt is not supposed to
be the better option.

--
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: Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

On Sat, Aug 1, 2015 at 1:28 PM, Brian Inglis  wrote:

 Seems like the problem may be developer confusion between strftime and
 printf conversion flag prefixes. The strftime space conversion flag
 character is _ so space filled seconds should use %_S, whereas the printf
 conversion flag character is space ' ', though I can't recall ever using
 that, as it is normally the default.

Well this code is not related to the strftime code in my other thread.
In this case it was just that a programmer didn't understand why
people do printf(%s,string) instead of printf(string). The program
takes lines out of log files, snarfs information out of them and makes
a report. Sometimes what belongs in the report is a copy of the entire
line from the log, so printf(line). But that would seem unwise in
general. In particular these log lines have prompts in them, and as
you know prompts often have '%' characters in them. It was only a
matter of time before this habit became a bad one.

So my email above is really the conclusion of the investigation, and
the fix is for me to switch the code to fputs in such cases.

--
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: Seg Fault in strftime

[Michael Enright]

On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote:
 It would be very helpful if you could tweak the testcase there and produce
 one which reproduces your problem.

 [1]
 https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=75d5f68aabf62c42884ff935f888b12bbcd1
 [2] https://sourceware.org/ml/newlib/2015/msg00321.html

I took one more shot at reproduction and I think the problem is that
if code does a member-by-member initialization based on the fields
defined by POSIX, it is likely that tm_zone won't be initialized and
it could end up with a really bad value. Then strftime is likely to
dereference it.

You can improve the likelihood of a crash by filling a struct tm with
0x54, like I did, but random circumstances could also effectively
cause the same thing.

We could implore the local Cygwin maintainer of mozjs to make sure
that the code I mentioned earlier in that library zeros the struct tm,
but there is only defensive programming recommending that, not a
specification. And there could be other libraries or applications
already tripping over this but not yet spending time on investigating
it.

If I took the time to think it through I think the additional logic
for handling a NULL tm_zone is not necessarily the cause of the
regression I'm facing, because the code I'm using through mozjs was
not setting that field to NULL in the first place.

I'm going to be away from the machines where I have this code at hand
for the next two weeks, reading email but not equipped to do anything
complicated about it.

--
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: Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote:

 I think you need to use the gdb command 'set cygwin-exceptions on' to tell
 gdb to break on exceptions inside the cygwin DLL (by default they are
 ignored, as they may be generated during normal operation when checking a
 pointer is valid)

 I shall have to see if I can find a place for these last couple of answers
 in the FAQ or documentation somewhere.  It's rather too obscure at the
 moment.


This is going to help, I have another application (which I don't even
know yet if it uses strftime because I didn't write it) that is
falling over in a similar fashion, with a different 0x61xx address
involved.

--
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: Seg Fault in strftime

[Michael Enright]

On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote:
 On 31/07/2015 01:16, Michael Enright wrote:

 It would be very helpful if you could tweak the testcase there and produce
 one which reproduces your problem.

 [1]
 https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=commitdiff;h=75d5f68aabf62c42884ff935f888b12bbcd1
 [2] https://sourceware.org/ml/newlib/2015/msg00321.html

I have not found it simple to reproduce the symptoms in the
intepreter, but I have found that if I do
struct tm manually_initialized;
manually_initialized.tm_year = 2000;
strftime(buf, buf_size, %Z, manually_initialized);
The printed time zone is garbage, which is an indication of danger.
Unlike my complex case, the tzname twins are not corrupted by this
exercise.

If I do
struct tm zeroed = {0};
manually_initialized.tm_year = 2000;
strftime(buf, buf_size, %Z, zero_initialized);
The printed time zone is PST (TZ happens to be America/Los_Angeles)

Aside: I am not super-certain of the zero-initialized semantics with
respect to the language. The idiom I used is defined in C++ but the
program is C.

--
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: Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

On Fri, Jul 31, 2015 at 11:46 AM, Michael Enright wrote:
 On Fri, Jul 31, 2015 at 5:51 AM, Jon TURNEY wrote:

 I think you need to use the gdb command 'set cygwin-exceptions on' to tell
 gdb to break on exceptions ...

 This is going to help, I have another application (which I don't even
 know yet if it uses strftime because I didn't write it) that is
 falling over in a similar fashion, with a different 0x61xx address
 involved.

The program in question is passing strings to printf that (a) end with
%  or (b) in the middle have % S. To be clear these strings are
the sole argument so they are format strings. This happens tons of
times during a run but eventually it crashes in printf, generating a
stackdump unless the magic setting is set.

As I read the posix spec, % can be followed by flags and space is
actually a flag. This flag affects how signs are handled for numeric
output. So it could be that the code is trying to deal with
%flagconversion-char and S is not a valid conversion char. My
attempts to reproduce this outside the evil program have not worked.
The output is a little crazy when you printf(something % Something)
but in my test program it doesn't crash. I tried printing the strings
that the real program might have to deal with but this didn't cause a
crash either.

I have modified the evil program so that in at least this one spot,
lines from the input file are not passed to printf to be output.

So there might be something, because an internal SEGV that actually
halts the program is bad, but I haven't got a good test case. I have
always disagreed with both printf(sometext) and printf(%s, sometext)
as wastes of cycles but I wasn't the one making the choices when the
evil program was written.

--
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: Seg Fault in strftime

[Michael Enright]

On Fri, Jul 31, 2015 at 12:50 PM, Michael Enright  wrote:
 If I do
 struct tm zeroed = {0};
 manually_initialized.tm_year = 2000;
 strftime(buf, buf_size, %Z, zero_initialized);
 The printed time zone is PST (TZ happens to be America/Los_Angeles)


Apologies, I actually did this consistently but the report above is wrong.
 struct tm zeroed = {0};
 zeroed.tm_year = 2000;
 strftime(buf, buf_size, %Z, zeroed);

--
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

Seg Fault in strftime

[Michael Enright]

In a thread about navigating a stackdump to find out what's going
wrong, I posted the output of a GDB session as follows.

On Thu, Jul 30, 2015 at 11:48 AM, Michael Enright  wrote:

 (gdb) print tznam
 $3 = 0xc07a4000 error: Cannot access memory at address 0xc07a4000
 (gdb) list
 1339tznam = _tzname[tim_p-tm_isdst  0];
 1340  /* Note that in case of wcsftime this loop only works 
 for
 1341 timezone abbreviations using the portable
 codeset (aka ASCII).
 1342 This seems to be the case, but if that ever
 changes, this
 1343 loop needs revisiting. */
 1344  size = strlen (tznam);
 1345  for (i = 0; i  size; i++)
 1346{
 1347  if (count  maxsize - 1)
 1348s[count++] = tznam[i];
 (gdb) print _tzname
 $4 = {0x800cfc48 \200, incomplete sequence \356\066, 0x800cfc44 PDT}
 (gdb) print _tzname[0]
 $5 = 0x800cfc48 \200, incomplete sequence \356\066
 (gdb) print _tzname[1]
 $6 = 0x800cfc44 PDT


This is a little misleading. The code at or near line 1339 looks like this:
1331 #if defined (__CYGWIN__)
1332 /* See above. */
1333  extern const char *__cygwin_gettzname (const struct tm *tmp);
1334  tznam = __cygwin_gettzname (tim_p);
1335 #elif defined (__TM_ZONE)
1336  tznam = tim_p-__TM_ZONE;
1337 #endif
1338  if (!tznam)
1339tznam = _tzname[tim_p-tm_isdst  0];

The tznam is set from the tmzone member and when this happens that
member is garbage. This member is garbage POSSIBLY because of a
configuration option in libmozjs. The calling code is in prmjtime.cpp
fills in a struct tm from Spidermonkey's own broken-down time
structure, 'a', and then if the configuration enables, it makes
*another* struct tm with more fields filled in in order to get
a.tm_zone's proper value. My guess is that the path is not enabled but
the bits delivered to me do not disclose whether this righteous code
path is enabled. __cygwin_gettzname is evidently compiled to expect
the tm_zone member to exist because GDB shows it does exist.

So did any aspect of this change recently? The application and library
were getting along okay before I did cygwin updates. The last time I
had tried to run this code was early June, at which time I was running
it dozens of times a day.

Also it appears that the tm_zone member is an extension. I haven't
been able to find POSIX guidance about how applications are supposed
use struct tm in compliance in the presence of implementation-defined
fields. POSIX example code shows a usage that does access the 'at
least' fields. The language allows for implementation-defined fields.
No mechanism is provided within POSIX to allow an application to
discover additional fields and take care of them. It seems to me that
an application can then assume that when it provides a struct tm as
input, filling in the time and date reasonably, it is always
sufficient to fill in the 'at least' fields and the implementation is
the one who has to assume that the rest of the fields might not be
filled in.

--
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: Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

On Thu, Jul 30, 2015 at 7:39 AM, Jon TURNEY  wrote:
 You need to install the 'cygwin-debuginfo' package for debug symbols for
 cygwin1.dll

I missed this in my searches. I see now that I should have used the
debug category.


 You also need to point addr2line at those detached debug symbols, as (unlike
 gdb) it doesn't follow .gnu_debuglink pointers.

 (I'm assuming you've typoed 6155d363 here and it should be 0x6115D363 as the
 strace output says)

I've been having trouble getting that number right


 # addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 0x6115D363
 /usr/src/debug/cygwin-2.1.0-1/newlib/libc/machine/i386/strlen.S:64

Another problem is that there's only one stack frame in the stack
dump, so knowing that it's a strlen just means I have to crank out
some grep commands and hopefully one of them is vulnerable to a
special case that now happens all the time.


 Are you sure the crashing process is the direct
 inferior of gdb, and not some wrapper process which runs it? (uninstalled
 libtool generated binaries do this, for e.g.)


The crashing executable is just a client of SpiderMonkey (via
libmozjs185) with several extensions to JavaScript in order to emulate
some of the Windows cscript utility and to emulate another environment
that happens to be a massive annoyance to run scripts in. The
executable is built using a textbook Makefile.

--
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: Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

On Thu, Jul 30, 2015 at 10:46 AM, Michael Enright  wrote:
 On Thu, Jul 30, 2015 at 7:39 AM, Jon TURNEY  wrote:
 You need to install the 'cygwin-debuginfo' package for debug symbols for
 cygwin1.dll

 I missed this in my searches. I see now that I should have used the
 debug category.


 You also need to point addr2line at those detached debug symbols, as (unlike
 gdb) it doesn't follow .gnu_debuglink pointers.

 (I'm assuming you've typoed 6155d363 here and it should be 0x6115D363 as the
 strace output says)

 I've been having trouble getting that number right


 # addr2line -e /usr/lib/debug/usr/bin/cygwin1.dbg 0x6115D363
 /usr/src/debug/cygwin-2.1.0-1/newlib/libc/machine/i386/strlen.S:64


So I set a breakpoint at that location. After hitting it a couple
dozen times I referred back to the stackdump for some register values.

I replaced the original breakpoint with b *0x6115D363 if $ecx==0
When that hit, I did a backtrace:

(gdb) bt
#0  strlen () at
/usr/src/debug/cygwin-2.1.0-1/newlib/libc/machine/i386/strlen.S:64
#1  0x6115bbc6 in __strftime (s=s@entry=0x28c1c8
(\274\a\200\300\t`\377\210\340`\377\001, maxsize=maxsize@entry=100,
format=0x6e7e86da js_Null_str+9683 Z),
format@entry=0x6e7e86d8 js_Null_str+9681 (%Z),
tim_p=tim_p@entry=0x28c0ec, era_info=era_info@entry=0x28c078,
alt_digits=alt_digits@entry=0x28c07c)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:1344
#2  0x6115d1bd in strftime (s=0x28c1c8
(\274\a\200\300\t`\377\210\340`\377\001, maxsize=100,
format=0x6e7e86d8 js_Null_str+9681 (%Z), tim_p=0x28c0ec)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:673
#3  0x610e9925 in _sigfe () at sigfe.s:38
#4  0x6e7e86d8 in js_Null_str () from /usr/bin/cygmozjs185-1.0.dll
#5  0x0028c0ec in ?? ()
#6  0x800392ec in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Then ...

(gdb) up
#1  0x6115bbc6 in __strftime (s=s@entry=0x28c1c8
(\274\a\200\300\t`\377\210\340`\377\001, maxsize=maxsize@entry=100,
format=0x6e7e86da js_Null_str+9683 Z),
format@entry=0x6e7e86d8 js_Null_str+9681 (%Z),
tim_p=tim_p@entry=0x28c0ec, era_info=era_info@entry=0x28c078,
alt_digits=alt_digits@entry=0x28c07c)
at /usr/src/debug/cygwin-2.1.0-1/newlib/libc/time/strftime.c:1344
1344  size = strlen (tznam);

Well, let's just kibitz myself:

(gdb) print tznam
$3 = 0xc07a4000 error: Cannot access memory at address 0xc07a4000
(gdb) list
1339tznam = _tzname[tim_p-tm_isdst  0];
1340  /* Note that in case of wcsftime this loop only works for
1341 timezone abbreviations using the portable
codeset (aka ASCII).
1342 This seems to be the case, but if that ever
changes, this
1343 loop needs revisiting. */
1344  size = strlen (tznam);
1345  for (i = 0; i  size; i++)
1346{
1347  if (count  maxsize - 1)
1348s[count++] = tznam[i];
(gdb) print _tzname
$4 = {0x800cfc48 \200, incomplete sequence \356\066, 0x800cfc44 PDT}
(gdb) print _tzname[0]
$5 = 0x800cfc48 \200, incomplete sequence \356\066
(gdb) print _tzname[1]
$6 = 0x800cfc44 PDT

So something happened when libmozjs tried to convert a time to a
string, and whatever happened has to do with the time zone.

--
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

Analyzing a SEG FAULT that gdb doesn't help with

[Michael Enright]

've got a program which was running but suddenly does not run.

I've been trying to debug in the usual way but all I get is a stackdump.

I consulted the internet for advice on how to use a stackdump and it
was pretty clear. I also brought LDD into the mix.

The IP register when the SEGV occurs is at 6155d363. Below are the
ranges per DLL that LDD prints for my system (updated today by the
way).

ntdll.dll = /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7784)
kernel32.dll = /cygdrive/c/Windows/syswow64/kernel32.dll (0x754a)
KERNELBASE.dll = /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x7582)
cygwin1.dll = /usr/bin/cygwin1.dll (0x6100)
cygexpat-1.dll = /usr/bin/cygexpat-1.dll (0x6f63)
cygmozjs185-1.0.dll = /usr/bin/cygmozjs185-1.0.dll (0x6e59)
cyggcc_s-1.dll = /usr/bin/cyggcc_s-1.dll (0x6f58)
cygstdc++-6.dll = /usr/bin/cygstdc++-6.dll (0x6d00)
cygffi-6.dll = /usr/bin/cygffi-6.dll (0x6f60)
cygnspr4.dll = /usr/bin/cygnspr4.dll (0x6df7)

So I tried to addr2line /usr/bin/cygwin1.dll 6155d363 and I got
nothing (?? at ??:?) I then reviewed in setup-x86 the possible cygwin
packages to see if there was a missing package I could use to enable
cygwin1.dll's addresses to be translated but I didn't recognize
anything.

I also tried strace. I got very little information regarding whatever
the programming failure is:
-8 cut here 8---
Installation of CLOCK_SYNC_GET_CAPS_EX.txt successful
  107 1561415 [main] cdiclient 4536 write: 54 = write(1, 0x801BA9F8, 54)
15458 1576873 [main] cdiclient 4536 fhandler_pty_slave::write: pty0,
write(0x801BA9F8, 17)
  121 1576994 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1852): pty output_mutex
(0x150): waiting -1 ms
   94 1577088 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1852): pty output_mutex:
acquired
  118 1577206 [main] cdiclient 4536
fhandler_pty_common::process_opost_output: (1891): pty
output_mutex(0x150) released

   99 1577305 [main] cdiclient 4536 write: 17 = write(1, 0x801BA9F8, 17)
--- Process 4536, exception c005 at 6115D363
77604 1654909 [main] cdiclient 4536 exception::handle: In
cygwin_except_handler exception 0xC005 at 0x6115D363 sp 0x28BFA4
  146 1655055 [main] cdiclient 4536 exception::handle: In
cygwin_except_handler signal 11 at 0x6115D363
-8 cut here 8---

There is a write to stdout immediately preceding the crash. I would
not guess that that is causing the problem. The write is using the
same buffer as the one just before it and any others I found and the
return value is equal to the byte count argument.

The write to stdout precedes the part of the program where I instruct
the JavaScript interpreter to call a function defined by the file that
has been interpreted already. It's possible that in the course of
executing that JavaScript it called into one of my JavaScript
extensions and that the problem lies there. But I can't even identify
where within cygwin1 or any other executable the SEGV occurred.


1) Why is it not the case that gdb handles this SEGV in the usual
manner? It too just allows the stackdump to be made and lets me know
that the inferior has run its course.

2) What tools have I overlooked in debugging this?

--
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] Updated: Tcl/Tk 8.5.18

[Michael Enright]

On Thu, May 21, 2015 at 7:06 PM, Steven Penny wrote:

 apt-cyg rdepends texlive |
 snip
 '

 Result

snip

Interesting.

For the lurkers, apt-cyg is not (yet?) available via
setup-x86{,_64}.exe and this SO question has info about obtaining it.
http://stackoverflow.com/questions/9751845/apt-get-for-cygwin

--
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] Updated: Tcl/Tk 8.5.18

[Michael Enright]

On Wed, May 20, 2015 at 8:22 PM, Steven Penny svnp...@gmail.com wrote:
 and have been using different versions of that script since. Installing Tcl/Tk
 with X11 is non-trivial:

 tcl   2,181,674
 tcl-tk5,691,785
 libX11_6745,228
 libXau6  18,626
 libXdmcp6   124,932
 libXext6220,188
 libXft2  42,224
 libXrender1  29,180
 libXss1  13,892
 libexpat158,104
 libfontconfig1  113,264
 libfreetype6369,440
 libpng16156,684
 libxcb1  35,116
 total compressed size: 9,800,337

Based on what I see getting updated, and some of the behaviors of the
resulting install on my three installations, that may be a low
estimate of the impact of X Windows. I'm not sure if the server is
using freetype, fontconfig or expat (it's conceivable) but let's
assume that the server does create those dependencies because a client
is not required to use any of them. The png library would seem to be
no part of X. And then there is the latest visible manifestation of
starting X, the X logo in the corner of the screen.

@Yaakov, many of us have a Cygwin requirement imposed on them for
reasons that maybe even you would argue against. Given that Cygwin
runs in a world where using GDI is economical and using X is costly,
and given that downloading and installing updates is a burden that
seems to grow ever larger as packages sprout dependencies on each
other, I would like to see the emergence of a new consensus that
clarifies to what extent X Windows is important to Cygwin as a whole.
It clearly is important to some programs but is it so essential to the
Cygwin ecosystem that the burden of using X is to be imposed on so
many unwilling Cygwin users?

--
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] Updated: Tcl/Tk 8.5.18

[Michael Enright]

On Thu, May 21, 2015 at 1:03 PM, Marco Atzeri marco.atz...@gmail.com wrote:
 If you look at the list of maintainers
 https://cygwin.com/cygwin-pkg-maint

 you will notice that it is very very short.

 Basically:
 Corinna is handling the cygwin core
 Yaakov is handlig  50% of the packages
 Jon is handling all the X server
 Achim is handling all perl
 Ken is handling all texlive
 Add me, Jary and Volker and we cover ~ 90% of all packages

 Please consider the additional burden you are asking to the
 limited maintainers' resources.

 Regards
 Marco


Thank-you for bringing this side of it to my attention. I think we all
participate or have participated at some point in projects where
tradeoffs of user effect vs developer time are made. I think it is
fair to escalate the question of where this balance is set from time
to time. I have used Cygwin for several years and only recently did I
have such a serious problem with it that I had to email this list for
support instead of working around the problem. I once had to counsel
customers to stick with Cygwin 1.5 because we didn't get approval to
fix our call to nc to match the version packaged in Cygwin 1.7,
given the balance of factors on our end. This is one understaffed
project forcing the hand of another understaffed project. We upgraded
our nc usage about two years after the problem was diagnosed,
because more and more users had downloaded a current version of Cygwin
and hit the 'nc' incompatibility.

--
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] Updated: Tcl/Tk 8.5.18

[Michael Enright]

On Thu, May 21, 2015 at 4:12 PM, Steven Penny svnp...@gmail.com wrote:
 On Thu, May 21, 2015 at 1:20 PM, Michael Enright wrote:
 I'm not sure if the server is using freetype

 snip
 tcl-tk  libXft2  libfreetype6  libpng16

 In the future, you might do your homework rather than waste my time.


My questions were about the X server, because I figured the server
could use some of those packages at least for doing its job. X clients
can theoretically have the server do their text for them, though it
seems to be less and less the case that clients are designed that way.
I certainly need more to know how to navigate whatever data is
available to me than to have others do it for me. I once was looking
for info on Cygwin packages and eventually found what I needed and
then found that the setup GUI had the answer. I am curious about how I
came to have a dependency on TeXlive in my installation even though I
don't need TeX. Where could I look for the info?

I come in peace.

--
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: [64bit] cygwin-devel headers broken

[Michael Enright]

When changing from compiler to compiler, even if it be just an OS
point version upgrade, implicit header inclusions go away all the
time. As a developer, I just shrug this off as one of the trade-offs
of choosing to develop in C or C++, which lack proper module systems.


On Fri, May 1, 2015 at 10:58 AM, Thomas Wolff t...@towo.net wrote:
 Am 01.05.2015 um 14:10 schrieb Jon TURNEY:

 On 01/05/2015 06:03, Marco Atzeri wrote:

 On 4/30/2015 8:52 PM, Thomas Wolff wrote:

 There is a crash issue induced on cygwin-64 (not on -32) after
 compilation with cygwin-devel 2.0.0 include files. I am recompiling my
 editor mined and it crashes, maybe immediately or after typing
 non-trivial input (like function keys, waiting for input with select()).
 ...


 I had a similar issue. But in my case the compilation fails as
 select seems gone:


 It seems that sys/select.h is no longer implicitly included by some other
 header, I think probably sys/time.h.

 Thanks for the hint, adding an include solves the issue.
 It had compiled without because I have a plain extern int select()
 declaration. It's obviously not a good declaration because the pointer
 arguments can now be 64 bit. (I think I could not unconditionally include
 select.h for porting compatibility with some legacy systems that don't have
 it.)

 Not sure whether it's a bug then as arguably a program using select should
 declare it properly. On the other hand this issue has not appeared on any
 other system and if traditionally include time.h used to imply include
 select.h maybe that should be maintained.
 --
 Thomas


 --
 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: Trouble with Git 2.1.x pushing to repos over Samba

[Michael Enright]

Corinna,

Do you think the snapshot would change the outcome in my case?

I haven't used a snapshot before. Is there a tutorial on how to get
onto and off of a snapshot? Or should I test by using a VM?

I myself am going to be on a short vacation and compressing too much
into tomorrow to do anything with a snapshot very soon.


On Thu, Apr 30, 2015 at 3:56 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
 Hi John,

 On Apr 30 18:44, John Orr wrote:
  From: Michael Enright
  $ git push origin master
  fatal: '//host/path/to/repo.git/' does not appear to be a git repository
  fatal: Could not read from remote repository.
 [...]
 #: john@johndesktop:/cygdrive/l ; ls -ld .git/objects/
 drwxr-xr-x 1 john Unix_Group+1000 0 Nov 13 14:13 .git/objects/

 (albeit, Corinna, with my group issue still not yet resolved)

 You tried the /etc/group tweak as I suggested in my latest mail in that
 thread, I take it?

 access(/cygdrive/l/.git, R_OK) returned 0
 access(/cygdrive/l/.git, W_OK) returned 0
 access(/cygdrive/l/.git, X_OK) returned -1

 The last test is the one run by git, that makes it reject my 
 /cygdrive/l/.git directory.

 Not sure if that's relevant, but just in case.

 Thanks for the info.  I found a really dumb bug in my code.  The
 access() function is using a Windows function for access checking under
 the hood.  To account for the Samba account mapping in Cygwin, there's
 a function converting the S-1-22-x-y SIDs in the file's ACL to Windows
 SIDs if there *is* a mapping.  But I made a small mistake which has
 a big result: The ACL is not completly copied over, thus the Windows
 function has to deal with an incomplete ACL.

 I fixed that in the git repo and uploaded new snapshots to
 https://cygwin.com/snapshots/  Please give them a try.  Don't use the
 snapshots for anything else for the time being!

   PLEASE TEST ASAP AND REPORT BACK!

   I'll be unavailable for a few weeks starting tomorrow, so I'd like to
   do a bugfix Cygwin release, preferredly today, if this patch works as
   desired.


 Thanks,
 Corinna


 P.S.: As a side-note: While this patch (hopefully) reverts this code to
   work as pre-1.7.34, it seems that the internal Windows access
   check function is not quite up to the task for Samba shares in
   scenarios as John's one.  It will always report back the access of
   the others part of POSIX permission bits.  Only with the new
   mapping of S-1-22-x-y SIDs to real WIndows accounts, or with
   winbindd-supported mapping, the Windows access check will really
   work as desired.

 --
 Corinna Vinschen  Please, send mails regarding Cygwin to
 Cygwin Maintainer cygwin AT cygwin DOT com
 Red Hat

--
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: Trouble with Git 2.1.x pushing to repos over Samba

[Michael Enright]

I can report that it worked for me.
$ uname -a
CYGWIN_NT-6.1-WOW Manticore 2.0.0(0.287/5/3) 2015-04-30 10:13 i686 Cygwin

I believe the above confirms that the DLL got installed. Then I did
the git push origin command and it worked.


On Thu, Apr 30, 2015 at 4:17 AM, Corinna Vinschen
corinna-cyg...@cygwin.com wrote:
 On Apr 30 04:11, Michael Enright wrote:
 Corinna,

 Do you think the snapshot would change the outcome in my case?

 I think so.

 I haven't used a snapshot before. Is there a tutorial on how to get
 onto and off of a snapshot? Or should I test by using a VM?

 Just download the cygwin DLL matching your architecture (x86/x86_64),
 that is

   http://cygwin.com/snapshots/x86/cygwin1-20150430.dll.xz or
   http://cygwin.com/snapshots/x86_64/cygwin1-20150430.dll.xz

 Unxz it, chmod +x it.  Exit all Cygwin processes (even services), move
 the original cygwin1.dll to a safe place.  Copy the snapshot DLL into
 its place, renaming it to cygwin1.dll.  Start a shell.  Test.  Exit the
 shell.  Remove the new DLL and move the original DLL back into its
 place.  That's it.


 Corinna

 --
 Corinna Vinschen  Please, send mails regarding Cygwin to
 Cygwin Maintainer cygwin AT cygwin DOT com
 Red Hat

--
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