Warren Young wrote:
On 4/25/2014 11:26, Tom Szczesny wrote:
CYGWIN_NT-6.1-WOW64
"WOW64" means 32-bit Windows emulated on top of 64-bit Windows.[1] This
tells you that Cygwin is running inside that 32-bit environment.
[snip]
You don't have to guess and hope, though. From 32-bit Cygwin:
$ file /bin/ls
/bin/ls: PE32 executable (console) Intel 80386 (stripped to external
PDB), for MS Windows
$ file /cygdrive/c/cygwin64/bin/ls
/cygdrive/c/cygwin64/bin/ls: PE32+ executable (console) x86-64, for MS
Windows
file(1) saith sooth what what form of executable thou hast wrought.
You might also find this piece enlightening: http://goo.gl/qv5ki7
That is enlightening. I have a rather different, and very non-standard
setup, making use of $PROCESSOR_ARCHITECTURE. This environment variable
is set in both 32-bit and 64-bit Cygwin. In the former, it's set to
"x86" and in the latter, it's set to "AMD64".
So, I have my 64-bit Cygwin root set to C:/cygwin/AMD64, and my 32-bit
Cygwin root set to C:/cygwin/x86. My package root for both is
C:\cygwin\packages, and I have /home in both environments mounted on
C:/cygwin/home.
I script all my builds, and the script I use sets the build directory
always to build_${PROCESSOR_ARCHITECTURE}. In a similar way, my output
files are named things like configure_${PROCESSOR_ARCHITECTURE}.out,
make_${PROCESSOR_ARCHITECTURE}.out, etc.
But, as you mention in your SO response, I'd never dream of sharing
/usr/local this way.
Oh, finally, I set the title of my mintty or xterm to contain
${PROCESSOR_ARCHITECTURE} as well, so I don't forget where I am.
--
Chris J. Breisch
--
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
