Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hi,

Having installed Cygwin with no errors I could see, I went on to
compile and run "hello world" - as you do. I could make it go from a
windows command prompt after modifying the system path to include
cygwin\bin, so - so far so good.

>From the cygwin terminal, however, the same executable refuses to play
ball. No text is shown; the command prompt returns instantly.

I have tried looking in the mailing list archive, and the answer may
well be there (in which case I apologise). But the searches I have
tried either returned nothing, or an incredible amount of information
that was not apparently relevant to my problem.

Maybe the attached strace output tells somebody something; to me its
only helpful thing is that it shows that the cygwin1.dll is found and
loaded, which eliminates the most likely potential problem that I
could see. Dependency Walker only mutters about 64-bit and 32-bit
libraries being mixed, but as the program runs under the Windows
command prompt, I am discounting that as a reason for the failure.

All the standard pre-compiled utilities I tried run as expected from
the cygwin terminal.

I'd be very grateful for a pointer!
Wouter van Doorn


cygcheck.out
Description: Binary data


hello.strace.out
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

Re: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hi René,

Thanks for your attempts at having me dig deeper. So far, I am not
striking lucky. Here's the various outputs, that don't say anything
obvious to me:
User-PC-> echo $PATH
/home/User/exe.CYGWIN:/home/User/bin:/usr/local/bin:/usr/bin:/cygdrive/c/ProgramData/Oracle/Java/javapath:/cygdrive/c/Program
Files/Dell/DW WLAN
Card:/cygdrive/c/Windows/system32:/cygdrive/c/Windows:/cygdrive/c/Windows/System32/Wbem:/cygdrive/c/Windows/System32/WindowsPowerShell/v1.0:/cygdrive/c/Program
Files/WIDCOMM/Bluetooth Software:/cygdrive/c/Program
Files/WIDCOMM/Bluetooth Software/syswow64:/cygdrive/c/Program
Files/Git/cmd:/usr/bin:.:/cygrive/c/cygwin/bin:/cygdrive/c/cygwin/bin

===>so yes, /usr/bin is there.

User-PC-> ldd hello.exe
ntdll.dll => /cygdrive/c/Windows/SysWOW64/ntdll.dll (0x7772)
kernel32.dll => /cygdrive/c/Windows/syswow64/kernel32.dll (0x768b)
KERNELBASE.dll => /cygdrive/c/Windows/syswow64/KERNELBASE.dll
(0x7723)
cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)

===>no missing items

User-PC-> file hello.exe
hello.exe: PE32 executable (console) Intel 80386, for MS Windows

===>nothing here that worries me either.

Any other thoughts?

No doubt overdone, but here's the code:
User-PC-> cat hello.c
#include 

int main(int arg, char **argv) {
printf("Hello, world!\n");
}

and compilation was just by make hello... The simplest thing ever,
you'd say... The only real clue as far as I can see is the exception
in the last line but one of the strace output. But I don't know how to
read that.

STOP PRESS: in gdb, the output IS there:
User-PC-> 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 "i686-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/c_dir/hello.exe
[New Thread 6868.0x5b0]
[New Thread 6868.0x18dc]
[New Thread 6868.0x1990]
Hello, world!
[Thread 6868.0x1990 exited with code 0]
[Inferior 1 (process 6868) exited normally]
(gdb)

Which is dandy, but then why, outside of gdb, is there nothing at all?
Still stumped!

Wouter

On 21 June 2017 at 22:48, René Berber  wrote:
> On 6/21/2017 4:10 PM, Wouter van Doorn wrote:
>
>> Having installed Cygwin with no errors I could see, I went on to
>> compile and run "hello world" - as you do. I could make it go from a
>> windows command prompt after modifying the system path to include
>> cygwin\bin, so - so far so good.
>>
>> From the cygwin terminal, however, the same executable refuses to play
>> ball. No text is shown; the command prompt returns instantly.
> [snip]
>
> It could be the program itself, i.e. not coded for a Posix environment,
> or it could be your PATH which should include /usr/bin (as shown, not as
> a Windows path C:\...)
>
> Easiest way to figure it out is by running:
>
> $ ldd hello (or whatever the name of your executable is)
> (sample output)
> ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffaf660)
> ??? => ??? (0x7779)
> wow64.dll => /cygdrive/c/WINDOWS/System32/wow64.dll (0x5aa4)
> wow64win.dll => /cygdrive/c/WINDOWS/System32/wow64win.dll
> (0x5aaa)
>
> In this case the missing cygwin1.dll doesn't even show its name, it
> happens to be the 32-bit version, because I ran ldd from a 64-bit Cygwin
> on a 32-bit Cygwin program, my PATH doesn't include the cygwin 32-bit
> binary directory.
>
> And if that doesn't show the missing libraries, then even
>
> $ file hello
>
> could show a clue, like "PE32+ executable (GUI) x86-64 (stripped to
> external PDB), for MS Windows" which is a GUI program compiled with
> MinGW, i.e. doesn't depend on Cygwin.  Cygwin is not mentioned in the
> output of file, even a Cygwin console program shows something like "PE32
> executable (console) Intel 80386, for MS Windows" or "PE32+ executable
> (console) x86-64, for MS Windows".
>
> Hope this helps.
> --
> R. Berber
>
>
> --
> 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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Nice thought, but no, that's not it. The standard utilities behave
normally, only the things I compile myself stay schtumm.

On 22 June 2017 at 14:57, cyg Simple  wrote:
>>
>> STOP PRESS: in gdb, the output IS there:
>> User-PC-> 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 
>> 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 "i686-pc-cygwin".
>> Type "show configuration" for configuration details.
>> For bug reporting instructions, please see:
>> .
>> Find the GDB manual and other documentation resources online at:
>> .
>> 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/c_dir/hello.exe
>> [New Thread 6868.0x5b0]
>> [New Thread 6868.0x18dc]
>> [New Thread 6868.0x1990]
>> Hello, world!
>> [Thread 6868.0x1990 exited with code 0]
>> [Inferior 1 (process 6868) exited normally]
>> (gdb)
>>
>> Which is dandy, but then why, outside of gdb, is there nothing at all?
>> Still stumped!
>
> Is your prompt overwriting the output of the program?
>
> Try:
>
> $ hello | cat
> $ hello | grep ello
>
> etc.
>
> --
> cyg 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
>

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

With 'outside', I meant a normal run not involving gdb at all. Sorry
if I was unclear.

Yes, it's minty, and it's /bin/bash.

Out of desperation, I have added a sleep for two seconds both before
and after the printf statement. The sleep does not happen either! The
prompt is immediately back, so it's more than just 'no output', it
seems my code never even gets started. Does this shed any new light?

On 22 June 2017 at 15:08, René Berber  wrote:
> On 6/22/2017 8:13 AM, Wouter van Doorn wrote:
>
> [snip]
>> STOP PRESS: in gdb, the output IS there:
>> User-PC-> gdb hello.exe
>> GNU gdb (GDB) (Cygwin 7.10.1-1) 7.10.1
> ...
>> Reading symbols from hello.exe...done.
>> (gdb) run
>> Starting program: /home/User/c_dir/hello.exe
>> [New Thread 6868.0x5b0]
>> [New Thread 6868.0x18dc]
>> [New Thread 6868.0x1990]
>> Hello, world!
>> [Thread 6868.0x1990 exited with code 0]
>> [Inferior 1 (process 6868) exited normally]
>> (gdb)
>>
>> Which is dandy, but then why, outside of gdb, is there nothing at all?
>
> What is "outside"?
>
> Are you running this from mintty (recommended) or the Cygwin.bat cmd window?
>
> Which shell? (i.e. echo $SHELL)
> --
> R. Berber
>
>
> --
> 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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Well, it's the same antivirus (comodo) that I earlier had a working
system with, and there's also the matter of it running fine under a
windows command prompt.

Thanks for all your suggestions!

On 22 June 2017 at 17:18, René Berber  wrote:
> On 6/22/2017 10:59 AM, Wouter van Doorn wrote:
>
>> With 'outside', I meant a normal run not involving gdb at all. Sorry
>> if I was unclear.
>>
>> Yes, it's minty, and it's /bin/bash.
>>
>> Out of desperation, I have added a sleep for two seconds both before
>> and after the printf statement. The sleep does not happen either! The
>> prompt is immediately back, so it's more than just 'no output', it
>> seems my code never even gets started. Does this shed any new light?
>
> Then its down to the 'weird' stuff, any anti-virus installed? (maybe
> even the name hello.exe could cause an anti-virus to block it).
> --
> R. Berber
>
>
> --
> 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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hi Andrey,

That looked really promising, as that whole rebasing stuff was
something I'd never heard about. Unfortunately, it did not lead to
anything; all my self-compiled tools still do exactly nothing.

Apologies about the top-posting; I had missed that rule.
Wouter

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hello Thomas,

Thanks for looking.

The tools are the original ones, as shown below:
User@User-PC ~/c_dir
$ ./hello.exe

User@User-PC ~/c_dir
$ type make
make is hashed (/usr/bin/make)

User@User-PC ~/c_dir
$ type gcc
gcc is /usr/bin/gcc

User@User-PC ~/c_dir
$ type cc
cc is /usr/bin/cc


If you know of anything more to check, I'll try almost anything, as
this is driving me up the walls!

Kind regards,
Wouter

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hi René,

There isn't one! The default rule does exactly that (although despite
the -o it creates a hello.exe, but that's fine.

Wouter

I'm convinced that the answer must lie hidden in the two differing
outputs of procmon, elsewhere in this thread. But I lack the knowledge
to go in deeper, and the development environment to correct it if I
didn't...

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hello again!

Thanks for your continued support.

Answers to your questions will follow, but I do need to say first that
there has been progress, and although the wy of getting there was
extremely vague, things now do work properly. I'll say more in a
general reply later. So the urgency is gone, but I still fail to
understand what happened. I can live with that, though not gladly.

Anyway.

Compiling/linking is done in the most elementary way, via make with no
makefile (so make hello from the source hello.c). Furthermore:

$ uname -a
CYGWIN_NT-6.1-WOW User-PC 2.8.0(0.309/5/3) 2017-04-01 20:42 i686 Cygwin

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/5.4.0/lto-wrapper.exe
Target: i686-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.i686/src/gcc-5.4.0/configure
--srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-5.4.0-1.i686/src/gcc-5.4.0
--prefix=/usr --exec-prefix=/usr --localstatedir=/var
--sysconfdir=/etc --docdir=/usr/share/doc/gcc
--htmldir=/usr/share/doc/gcc/html -C --build=i686-pc-cygwin
--host=i686-pc-cygwin --target=i686-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix
--libexecdir=/usr/lib --enable-shared --enable-shared-libgcc
--enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --enable-__cxa_atexit --with-dwarf2
--with-arch=i686 --with-tune=generic --disable-sjlj-exceptions
--enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++
--enable-graphite --enable-threads=posix --enable-libatomic
--enable-libcilkrts --enable-libgomp --enable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libjava --enable-libgcj-sublibs
--disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --enable-linker-build-id
--with-default-libstdcxx-abi=gcc4-compatible
Thread model: posix
gcc version 5.4.0 (GCC)

$ ld -v
GNU ld (GNU Binutils) 2.25.2

I am unclear about the attachments you mention - I don't know what was
expected. But the urgency is gone, even if the mystery is not.

Kind regards,
Wouter

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Hello Cygwin-helpers,

Many thanks to all who have responded. It was good not to sit here
alone behind my keyboard tearing my hair out.

I'll outline what has heppened next especially for the benefit of
those readers who find themselves with this same problem. It would be
nasty to leave them in the lurch if I now only said 'thanks - it's
fine now'.

But things have now taken a strange/miraculous turn for the better. It
started with a suggestion from Achim about the general crappiness of
my PATH (fair), with a very specific request concerning the path by
Houder soon after. That was to recompile/link and re-run after setting
the PATH to just /usr/bin and nothing more.

To my relief, the resulting executable worked. Not just under the
command prompt, but also under mintty this time.

>From there, it seemed an easy task to find what the path component was
that caused the whole mess, but... it wasn't. Because now that it once
worked as expected, I was NEVER able to get it to go wrong again. I
re-instated the troublesome path, removed and rebuilt the executable,
and it is now still fine. Did the same after a shutdown/restart. No
change - everything is now as it should have been from the start.

So the message to those with the same problem is: try recompiling with
the PATH set to /usr/bin. After that, you may, just like me,
experience some sort of magic that means the fault disappears.

I'd rather know what was wrong, and what really happened to make the
error go away, but I can live with how it is. If developers want me to
run specific tests, I'll be very happy to do so. Otherwise, I'd say we
should consider this closed (but not forgotten).

Thanks again to all who chipped in - it was really apreciated.
Wouter

On 21 June 2017 at 22:10, Wouter van Doorn  wrote:
> Hi,
>
> Having installed Cygwin with no errors I could see, I went on to
> compile and run "hello world" - as you do. I could make it go from a
> windows command prompt after modifying the system path to include
> cygwin\bin, so - so far so good.
>
> From the cygwin terminal, however, the same executable refuses to play
> ball. No text is shown; the command prompt returns instantly.
>
> I have tried looking in the mailing list archive, and the answer may
> well be there (in which case I apologise). But the searches I have
> tried either returned nothing, or an incredible amount of information
> that was not apparently relevant to my problem.
>
> Maybe the attached strace output tells somebody something; to me its
> only helpful thing is that it shows that the cygwin1.dll is found and
> loaded, which eliminates the most likely potential problem that I
> could see. Dependency Walker only mutters about 64-bit and 32-bit
> libraries being mixed, but as the program runs under the Windows
> command prompt, I am discounting that as a reason for the failure.
>
> All the standard pre-compiled utilities I tried run as expected from
> the cygwin terminal.
>
> I'd be very grateful for a pointer!
> Wouter van Doorn

--
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: Compiled programs fail to run from Cygwin Terminal, but work from windows cmd

[Wouter van Doorn]

Ho-hum.

One day on, and it's all reverted. Everything failing again in exactly
the same way as before. It was too good to be true...

I'll have to give up on cygwin, still appreciate the attempts at helping me.
Wouter

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

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

[Wouter van Doorn]

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

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 (0x77bd)
kernel32.dll => /cygdrive/c/Windows/system32/kernel32.dll (0x77ab)
KERNELBASE.dll => /cygdrive/c/Windows/system32/KERNELBASE.dll
(0x7fefda7)
cygwin1.dll => /usr/bin/cygwin1.dll (0x18004)

$ 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 
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:
.
Find the GDB manual and other documentation resources online at:

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

[Wouter van Doorn]

Hi Marco,

No difference at all.
$ gcc -Wall -o ciao hello.c
$ ./ciao
$ echo $?
0
$

Am not familiar with the assembler, so I don't know what you were
hoping to achieve with that flag, but whatever it was, it didn't do
it! Thanks for trying,
Wouter

--
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: Compile/run problems on cygwin not solved by going to cygwin64

[Wouter van Doorn]

Hi Vince,

If they are related, then solving the problem that's my real current
issue will make the strace one go away. If they are not, then I am
about to start a second wild goose chase. Sticking with the problem
that I am immersed in now in the hope to get that resolved seems to be
my best bet.

I would like the strace issue to go away, of course, and if someone
has the magic bullet for it I am only too happy to get that issue out
of the way!

Kind regards, and thanks,
Wouter

On 28 June 2017 at 22:02, Vince Rice  wrote:
>> On Jun 28, 2017, at 3:00 PM, Wouter van Doorn wrote:
>> …
>> 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.
>
> You should. If strace won't run, you have a problem, and I would bet the odds 
> of the problems being related (or the same) is pretty 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
>

--
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: Compile/run problems on cygwin not solved by going to cygwin64

[Wouter van Doorn]

And now, finally, it seems that member Houder managed to nail it!

Virusscanner.

More specifically: the auto-containment policy of Comodo Antivirus.
I've used Comodo for a very long time, certainly from before the
moment that they have added that feature, which is essentially a
white-list of allowable executables. Something I abhor, and would
never have enabled. But it was rolled in, probably via an automatic
update, and it works.

It explains why MY programmes (never on any whitelist) would be
discarded. It explains why the standard tools like cat, grep etc.
would be allowed to run, and even why my program would be allowable
when started in a gdb session.

Not, to my mind, why the command prompt would have been able to start
my stuff, but I'll turn a blind eye to that...

I have disabled auto-containment, and can now run my programmes as I
expected to be able to.

Very surprised that this has not caused more users the same problem,
but if it happens to anyone else, I hope that this thread will help
them.

Thanks to all who have looked at this, and I hope I will not have to
bother any of you again.

Kind regards,
Wouter

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

XTerm always gives out an error message concerning a font

[Wouter van Doorn]

Hi all,

I have to admit to being almost totally ignorant on fonts under X11.
So not only do I not know how to fix what's happeing (and I found
nothing relevant by searching via google), but I think I also lack the
knowledge to make a mess of it. In fact: I never touched anything to
do with fonts after installing. So I would not expect anything to be
wrong, really.

Here's the error, and it crops up every single time an term is started:
/usr/bin/xterm: cannot load font
"-Misc-Fixed-bold-R-*-*-18-120-100-100-C-180-ISO10646-1"

This happens with both of these .Xresources file contents:
1)
XTerm*font: *-fixed-*-*-*-18-*
XTerm.*.scrollBar: true
XTerm.*.scrollbar.width: 8

2)
XTerm*font: *-fixed-*-*-*-18-*-ISO8859-*
XTerm.*.scrollBar: true
XTerm.*.scrollbar.width: 28

And I know for a fact that the content is processed, because if I play
around with the scrollbar width (as shown) that works a treat (so xrdb
-merge is not my problem).

File .xsession-errors is empty.

I've attached those files that I know I'd want to look at, but there
may be (many) more - let me know what else is needed and I'll supply
as quickly as I can.

Thanks for looking,
Wouter


xwin-server.log
Description: Binary data


cygcheck.out
Description: Binary data


XWin.0.log
Description: Binary data


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

Re: XTerm always gives out an error message concerning a font

[Wouter van Doorn]

Thanks, Brian. Your link shows me a page that mentions problems in
xterm-327 through 329, but I have 330, so although the symptom is very
similar, it doesn't seem to be that.
Wouter

--
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 always gives out an error message concerning a font

[Wouter van Doorn]

No luck with either of the fixed-medium suggestions. The one you
mentioned as default first match on your system is the one I get it
moaning about no matter what I do.

The easiest solution (of sorts) might be to go back to xterm patch
326, but I don't know how to do that either. The installer won't go
back further than 329. Or is that mirror-dependent, maybe? Is there a
mirror that goes back further than the sargasso uk one I have
selected?

Any pointers will be appreciated. BTW: it seems rather unlikely that
I'm the only one to have this problemette?

Thanks,
Wouter

--
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: Challenge: a VERY strange problem with command substitution in bash

[Wouter van Doorn]

I bet Comodo is the golden tip. They have introduced whitelisting
without telling anyone, and I have had very strange behaviour (strange
until that whitelist explained it) too. Including that subshell thing.
They call it 'auto-containment'. Just disable that, and done.
Wouter

On 12 July 2017 at 00:22, Richard Beels via cygwin  wrote:
> At 07/11/2017 at 15:12, Shakespearean monkeys danced on Jürgen Wagner's
> keyboard and said:
>>
>> ...
>> Using backquotes instead of the command substitution with $(...) does not
>> change the results. I could swear this did work in an earlier version of
>> Cygwin on my Windows 7 machine.
>>
>> I tried this to see if the code in the parentheses is executed at all:
>>
>> $ value="$( date 2> foo | cat )"; echo "$? <$value>"
>>
>> The file "foo" was not created, i.e., it seems the commands don't really
>> get executed.
>>
>> $ value="$( date && pwd )"; echo "$? <$value>"
>> 0 > /home/juergen>
>>
>> $ value="$( date || pwd )"; echo "$? <$value>"
>> 0 
>>
>> both work, so some control structures seem to be permissible... just not a
>> pipe.
>>
>> What is going on? Some misconfiguration? A Cygwin bug? Some interaction
>> with something weird in Windows 10? I am at loss to understand what could be
>> wrong... and am now most curious whether anybody has an idea what is causing
>> this. Does it work/not work in the same way in your Cygwin installation?
>>
>> I came across this effect because ssh-host-config did not recognize me as
>> administrator anymore. It's due to a check for a certain user group that
>> uses a command substitution with a pipe. Replacing this with an equivalent
>> command works. The original line used "id -G" and then a "grep -Eq" to check
>> whether a certain group is on that list.
>>
>> I am VERY curious now! I've rarely been puzzled that much by such a very
>> elementary shell expression (looking back at 34 years of Unix experience).
>
>
>
> Hi Jurgen.
>
> 90% chance it's what is called bloda in these parts.  It's in the FAQ on
> cygwin.com.  I'll go out on a limb and say you might have just
> installed/changed your AV/Firewall software.
>
> And if I want to be super-psychic, can I guess comodo?  Because I just
> changed to comodo a couple weeks ago and had the same subshell/command
> substitution/pipeline errors you're mentioning.
>
> If so, you need to exclude your cygwin folder from AV scanning. AND...  if
> the software does whitelisting or host intrusion protection (HIPS) or "run
> unknown executables in a container/sandbox" or something similar, you also
> need to trust all the executables, too.  Or switch to something else that
> doesn't trip cygwin's trigger.
>
> After doing that and a rebaseall, I haven't had a fork error in a week.  I
> can't wait to run setup and come up with an update process, though...
>
> Cheers!
>
>
>
> --
> 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

bash pipe fails in script with subshell/loop cmbination

[Wouter van Doorn]

Hi all,

I've run into a problem regarding pipes in bash, in a command that
loops. I've reduced it to a very small one-liner that fails. The two
versions below should, I'm sure, give the same output - but they
don't. I know the command is silly and useless as it is shown here,
but it's what I'm left with from something more complex after removing
as much of the complexity as I could while retaining the actual
problem I'm fighting.

ONE - this works as expected
$ for j in 1 2;do echo $j $(echo hello);done
1 hello
2 hello

TWO - this fails, apparently (warning: my guess) at the pipe
$ for j in 1 2;do echo $j $(echo hello | cat);done
1
2

THREE - To make it that bit more obscure, the following command also
works as it should, which by now I did not expect:
$ echo hello $(echo world | cat)
hello world

If 'cat' (in TWO) is replaced by 'od -a', then od does not generate
any output (at all) either. Can someone tell me what's wrong either in
what happens or in my expectation?

I have found someone on stackexchange who may, I think, be related
(https://unix.stackexchange.com/questions/364765/store-command-output-in-variable-when-command-includes-pipes)
but unfortunately that was not resolved. I tried it with virusscanning
switched off - no difference.

Thanks for looking!

Wouter van Doorn

Cygwin Configuration Diagnostics
Current System Time: Tue Aug 08 14:49:03 2017

Windows 7 Professional Ver 6.1 Build 7601 Service Pack 1

Path:   C:\cygwin64\home\User\exe.CYGWIN
C:\cygwin64\home\User\bin
C:\cygwin64\usr\local\bin
C:\cygwin64\bin
C:\Windows\system32
C:\Windows
C:\Windows\System32\Wbem
C:\cygwin64\bin
.

Output from C:\cygwin64\bin\id.exe
UID: 197608(User)  GID: 197121(None)
197121(None)   545(Users)
4(INTERACTIVE) 66049(CONSOLE LOGON)
11(Authenticated Users)15(This Organization)
113(Local account) 4095(CurrentSession)
66048(LOCAL)   262154(NTLM Authentication)
401408(Medium Mandatory Level)

SysDir: C:\Windows\system32
WinDir: C:\Windows

Here's some environment variables that may affect cygwin:
PWD = '/cygdrive/c/users/user/desktop/bewerkt/2017/20170301/Canon G15'
HOME = '/home/User'

Here's the rest of your environment variables:
TVlines = '40'
USERDOMAIN = 'User-PC'
OS = 'Windows_NT'
COMMONPROGRAMFILES = 'C:\Program Files\Common Files'
PROCESSOR_LEVEL = '6'
PSModulePath = 'C:\Windows\system32\WindowsPowerShell\v1.0\Modules\;C:\Program 
Files (x86)\AutoIt3\AutoItX'
CommonProgramW6432 = 'C:\Program Files\Common Files'
BIN = '/home/User/bin'
BUGPLATFORM = 'CYGWIN'
CommonProgramFiles(x86) = 'C:\Program Files (x86)\Common Files'
FP_NO_HOST_CHECK = 'NO'
LANG = 'en_US.UTF-8'
TZ = 'Europe/London'
i = '260_2302'
DISPLAY = ':0.0'
HOSTNAME = 'User-PC'
PUBLIC = 'C:\Users\Public'
OLDPWD = '/cygdrive/c/users/user/desktop/bewerkt/2017/20170301'
CYGWIN_NT61 = 'GENERIC'
EDITOR = 'gvim'
USERNAME = 'User'
LOGONSERVER = '\\USER-PC'
PROCESSOR_ARCHITECTURE = 'AMD64'
EXE = '/home/User/exe.CYGWIN'
LOCALAPPDATA = 'C:\Users\User\AppData\Local'
COMPUTERNAME = 'USER-PC'
SYSTEMDRIVE = 'C:'
BUGLIB = '/home/User/c_dir/buglib'
USERPROFILE = 'C:\Users\User'
PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC'
SYSTEMROOT = 'C:\Windows'
PROCESSOR_IDENTIFIER = 'Intel64 Family 6 Model 78 Stepping 3, GenuineIntel'
TMP = '/tmp'
HOST = 'User-PC'
windows_tracing_logfile = 'C:\BVTBin\Tests\installpackage\csilogfile.log'
PROCESSOR_REVISION = '4e03'
tvb = '/home/User/.uxtv_6.3/tv.CYGWIN -txterm '
PROFILEREAD = 'true'
NUMBER_OF_PROCESSORS = '4'
ProgramW6432 = 'C:\Program Files'
windows_tracing_flags = '3'
uxtv_version = '6.3'
COMSPEC = 'C:\Windows\system32\cmd.exe'
APPDATA = 'C:\Users\User\AppData\Roaming'
SHELL = '/bin/bash'
TERM = 'cygwin'
PLATFORM = 'CYGWIN'
TVback = '/home/User/.tvback'
WINDIR = 'C:\Windows'
ProgramData = 'C:\ProgramData'
SHLVL = '1'
PRINTER = 'Dell C1760nw (bw)'
PROGRAMFILES = 'C:\Program Files'
TVexe = '/home/User/.tvexe'
ALLUSERSPROFILE = 'C:\ProgramData'
TEMP = '/tmp'
TVhome = '/home/User/.uxtv_6.3'
SESSIONNAME = 'Console'
ProgramFiles(x86) = 'C:\Program Files (x86)'
PS1 = 'User-PC-> '
PS2 = '-> '
HOMEDRIVE = 'C:'
INFOPATH = '/usr/local/info:/usr/share/info:/usr/inf

Re: bash command substitution

[Wouter van Doorn]

Try the following:

echo $(echo hello | cat)

If that remains empty, (it should of course result in 'hello') you're
suffering from the same problem I have. And no, I did not get it resolved.
In which case I'd be elated if you could get anyone interested in finding a
solution!

If this happens to you, too, then the problem is that the pipe in a
subshell simply does not work. For the vast majority, it DOES work.

On 1 October 2017 at 18:01, Steven Penny  wrote:

> On Sun, 1 Oct 2017 08:40:51, Vukovics Mihaly wrote:
>
>> VHEIGHT=$(ffprobe -v error -show_entries stream=width,height -of
>> default=noprint_wrappers=1 ${OLDFILE} | grep "height" | cut -f2 -d'=')
>>
>> For debugging purpose the same command is executed without putting the
>> result into a variable, and works! Does anyone know why is it not working
>> in cygwin?
>>
>
> I am not having this trouble:
>
>$ VHEIGHT=$(ffprobe -v 0 -of compact=p=0:nk=1 -select_streams 0 \
>-show_entries stream=height 'The Master (2012).mp4')
>
>$ echo "$VHEIGHT"
>1040
>
> but as Marco said, you might need to sanitize for carriage returns:
>
>$ echo "$VHEIGHT" | od -tcx1
>000   1   0   4   0  \r  \n
> 31  30  34  30  0d  0a
>
>
>
> --
> 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