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.
cygcheck.out
Description: Binary data
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
