Compile/run problems on cygwin not solved by going to cygwin64

[Wouter van Doorn <vandoornw at gmail dot com>]

Hello all,

Recently, I started a thread named 'Compiled programs fail to run from
Cygwin Terminal, but work from windows cmd'. I got a lot of angles to
look at, but the golden tip wasn't there yet. One advice I had until
now laid aside was to use the 64-bit Cygwin version on my 64-bit
(Win7) machine instead of the 32-bit one. This I have now done. (There
was a reason for the 32-bit choice, but this is not the time/place to
go into that.)

After de-installing in accordance with the online guide
(https://cygwin.com/faq.html#faq.setup.uninstall-all) the new
installation went OK. The only surprising thing was that, unlike
during the previous installation, the Windows system path was not
updated to include the path to the cygwin1.dll file. Easily rectified
by hand, but slightly worrying.

The result is, unfortunately, still exactly the same:
== The Question ==>
When I compile a C program, the resulting executable runs fine under
the Windows command prompt, but does nothing in the Mintty terminal -
any program I compile will terminate immediately and not do anything
at all. How do I get this to behave as expected?
<===============

I will put together everything in this mail that was asked for in the
earlier thread (on the 32-bit version), in the hope to have a clearer
and more complete starting point. The other thread became very
fragmented with various people asking bits of information (also away
from the thread) that I then supplied piecemeal.

First of all: this is the program: hello.c (there is no makefile):
==============================
$ cat hello.c
#include <stdio.h>
#include <unistd.h>

int main(int argc, char **argv) {
   sleep(2);
   printf("Hello, world!\n");
   sleep(2);
}
==============================

This is the output for the relevant types:
==============================
$ type make gcc ld
make is /usr/bin/make
gcc is /usr/bin/gcc
ld is /usr/bin/ld
==============================

And here is some version information:
==============================
$ uname -a
CYGWIN_NT-6.1 User-PC 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
$ bash --version; gcc --version; ld --version; make --version ##
edited for version number only
GNU bash, version 4.4.12(3)-release (x86_64-unknown-cygwin)
gcc (GCC) 5.4.0
GNU ld (GNU Binutils) 2.25.2
GNU Make 4.2.1
==============================

The default environment for the user ('User') is not changed, except
for the path. The path is set to:
==============================
$ echo $PATH
/usr/local/bin:/usr/bin:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/cygwin64/bin
==============================

Compiling/linking (via make hello) runs OK. This was done in the
Mintty terminal. Then, under the Windows prompt, the following
happens:
==============================
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation.  All rights reserved.

C:\Users\User>cd \cygwin64\home\user

C:\cygwin64\home\User>echo %PATH%
C:\ProgramData\Oracle\Java\javapath;C:\Program Files\Dell\DW WLAN
Card;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\Program
Files\WIDCOMM\Bluetooth Software\;C:\Program Files\WIDCOM\Bluetooth
Software\syswow64;C:\Program Files\Git\cmd;C:\cygwin64\bin;

C:\cygwin64\home\User>hello.exe
Hello, world!
==============================
and the sleeps before and after printing are observed.

In the mintty terminal, this is what happens (and that's the problem):
==============================
$ echo 1;./hello.exe;echo 2
1
2
==============================
and there is no delay between the printing of 1 and 2 (no sleep(2) is executed).

My shell is bash;
==============================
$ echo $0
-bash
==============================

This is what ldd has to say about the linkage, and file about the whole:
==============================
$ ldd hello.exe
        ntdll.dll => /cygdrive/c/Windows/SYSTEM32/ntdll.dll (0x77bd0000)
        kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x77ab0000)
        KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7fefda70000)
        cygwin1.dll => /usr/bin/cygwin1.dll (0x180040000)

$ file hello.exe
hello.exe: PE32+ executable (console) x86-64, for MS Windows
==============================

When running hello.exe in gdb, the program *does* run correctly:
==============================
$ gdb hello.exe
GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-cygwin".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from hello.exe...done.
(gdb) run
Starting program: /home/User/hello.exe
[New Thread 1384.0x934]
[New Thread 1384.0x1114]
[New Thread 1384.0xaf8]
Hello, world!
[Thread 1384.0xaf8 exited with code 0]
[Inferior 1 (process 1384) exited normally]
(gdb)
==============================
And the sleeps are done.

I can't give the strace output, as 'strace ./hello.exe' causes an
immediate segmentation fault. No idea why, but not something I'm going
to put energy into right now.

Other things to note:
- all standard utilities like cat, grep, ... work fine.
- my antivirus is the free Comodo suite.
- I saw that rebasing was done during the install. Besides: the
program works under gdb and under the windows command prompt, so it
can't be that bad.
- Cygwin was installed under an administrator account.
- A suggested memory test is still pending, but I have to admit to not
finding that a likely cause - not with many a computer restart in
between, and with the exact same problem occurring on the 32 and 64
bit installs.
- Also pending is a suggestion to go to it with tools called sysmon,
address/memory sanitiser and valgrind. None of which I have any
experience with, so that's a project in itself.  Of these, valgrind
seems the most immediately useful in my case, so that'll be my next
port of call if there is no-one with the proverbial lightbulb
switching on.

And there you have it. I am (still) stuck.

Attachments:
- cygcheck.out for details of the installation
- installed.db with moreother details of the installation
- PML-files with details of runs as gathered by ProcMon (the 'thread
exit' after closing the file on cygwin1.lib MUST be the clue - for
someone other than me - but could not be attached because the size was
too big. These are available by mail for whoever is interested.

Attachment: cygcheck.out
Description: Binary data

Attachment: installed.db
Description: Binary data

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