i686-w64-mingw32-gcc via ssh and hence without /usr/bin on PATH fails

[Arthur Norman <acn1@cam.ac.uk>]

In 2014 there was a query about i686-w64-mingw32-gcc in the case that 
/usr/bin was not on the PATH, and the responses then said that the issue 
would be fixed in the next release.

I got bitten now because when I use ssh to execute a command on a remote 
cygwin64 system /bin gets on PATH but /usr/bin does not. The use case is 
that the Windows10/cygwin setup is in a virtualbox VM, and the cygwin was 
only installed with the components I needed for my use of it.

This shows ssh from the Ubuntu64 host to the Windows10/cygwin64 host with 
PATH set up in a somewhat minimal manner.
ssh -p 18664 localhost echo \$PATH
/bin:/cygdrive/c/WINDOWS/system32:/cygdrive/c/WINDOWS:/cygdrive/c/WINDOWS/System32/Wbem:/cygdrive/c/WINDOWS/System32/WindowsPowerShell/v1.0:/cygdrive/c/Users/cyg_server/AppData/Local/Microsoft/WindowsApps

Now here are some examples that start with a very basic "hello world" 
program in C (main() only contains a call to printf) in a variety of ways 
run from a cygwin64 shell on a Windows machine

acn1@panamint ~ i686-w64-mingw32-gcc hello.c -o hello
    compilation locally goes without fuxx

acn1@panamint ~ /usr/bin/i686-w64-mingw32-gcc hello.c -o hello
    specifically invoking the compiler from /usr/bin is OK

acn1@panamint ~ /bin/i686-w64-mingw32-gcc hello.c -o hello
/tmp/cck2N9Nc.s: Assembler messages:
/tmp/cck2N9Nc.s:12: Error: invalid instruction suffix for `push'
    specifically invoking the compiler from /bin fails in a way that I
    believe probably relates to confusion between 32 and 64-bit assembly
    code.

acn1@panamint ~ ssh localhost i686-w64-mingw32-gcc hello.c -o hello
/tmp/ccK5oXEh.s: Assembler messages:
/tmp/ccK5oXEh.s:12: Error: invalid instruction suffix for `push'
    Remote executtion of the compiler via ssh will not have /usr/bin on
    PATH and fails.

acn1@panamint ~ ssh localhost "PATH=/usr/bin:\$PATH; i686-w64-mingw32-gcc 
hello.c -o hello"
    If I explicitly put /usr/bin back on PATH then the compilation is
    OK again.

Having uncovered this as an apparent root of problems that I was having I 
can now make my scripts use this final recipe and so I can make progress 
again, but this feels pretty odd and somewhat unsatisfactory... and maybe 
some others will get caught by it?

So so far as I am conncerned now I have a fix this is no longer urgent, 
but it is perhaps best reported.

    Arthur Norman




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