From: David Allsopp <David.Allsopp@cl.cam.ac.uk>
To: "cygwin@cygwin.com" <cygwin@cygwin.com>
Subject: RE: Cygwin x86 on Windows 10 ARM64
Date: Thu, 12 Jul 2018 13:34:00 -0000 [thread overview]
Message-ID: <E51C5B015DBD1348A1D85763337FB6D901ADB51D5E@Remus.metastack.local> (raw)
In-Reply-To: <20180712091434.GR27673@calimero.vinschen.de>
Corinna Vinschen wrote:
> On Jul 12 07:46, David Allsopp wrote:
> > Corinna Vinschen wrote:
> > > On Jul 10 10:51, David Allsopp wrote:
> > > > I've been trying out the x86 emulation in Microsoft's ARM64
> > > > version of Windows 10 1803.
> > > >
> > > > I had two issues with Cygwin x86. The first, which is simple, is
> > > > that Windows doesn't by default create
> > > > C:\Windows\SysWOW64\drivers\etc which causes
> > > > /etc/postinstall/base-files-mketc.sh to exit with an error all the
> > > > time. I wonder if there's a possible workaround to make
> > > that less intrusive?
> > >
> > > Try if C:\Windows\Sysnative\drivers\etc works. That should be the
> > > easiest way to fix the issue in the script.
> >
> > It does indeed. Certainly seems like a good fallback (if not possible
> > default, although I'm sure someone out there takes advantage of a
> > different hosts file between 32-bit and 64-bit!!). I'm happy to tweak
> > the script if you can remind me where its repo is?
>
> https://sourceware.org/cygwin-apps/ has a list of Cygwin-specific projects
> hosted on cygwin.com. The base-files project is maintained by Achim
> Gratz. Please send patches to the cygwin-apps mailing list.
Thanks - will do!
> > > > The error message implies that it may have computed the wrong
> > > > directory, which it hasn't - it's just that the directory doesn't
> > > > exist.
> > > >
> > > > The other is that all Cygwin binaries are emitting the "Could not
> > > > compute FAST_CWD pointer" warning.
> > >
> > > Nothing we can do about, unless somebody dives into assembler code
> > > on such a system. If the code switches to ARM64 early, this could
> > > be tricky.
> >
> > The machine I'm using is only for testing on this platform - I can
> > grant access to it if it'd be worth looking into?
> >
> > > As a workaround I pushed a patch to check for running in WOW64 under
> > > ARM64. The warning is skipped then. The already existing fallback
> > > code should work most of the time. Just give the latest developer
> > > snapshot from https://cygwin.com/snapshots/ a try.
> >
> > OK, so this is very weird - both GetNativeSystemInfo and GetSystemInfo
> > are returning 0 in both wProcessorArchitecture and wReserved (and FWIW
> > 586 in dwProcessorType). This is with GCC 6.4.0 (i686-w64-mingw32-gcc)
> > and with Microsoft's own **x86** Cl (19.15.26629.1 in VS 2017.8
> > Preview 4). My test program is simply:
>
> This looks like a bug in the emulator. You may want to contact Microsoft.
Indeed - I can't install the fast ring insider build on this machine (driver problem <sigh>) but I'm now trying the slow ring instead.
> Nevertheless, we can use the current buggy reply to our advantage:
> We know we're running in an emulator. The value of wProcessorArchitecture
> returned by GetNativeSystemInfo should never be 0. 6, 9, 12 are ok, but
> 0???
Seems reasonable!
> So, if the GetNativeSystemInfo returns 0 we can still skip the warning.
> For completeness, I'd like to see the output of `uname -a'
> in Cygwin, though.
CYGWIN_NT-10.0-WOW Envy 2.11.0(0.327/5/3) i686 Cygwin
David
--
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
next prev parent reply other threads:[~2018-07-12 11:04 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-10 9:51 David Allsopp
2018-07-10 13:04 ` Corinna Vinschen
2018-07-11 16:13 ` Brian Inglis
2018-07-12 11:04 ` David Allsopp
2018-07-12 12:04 ` Corinna Vinschen
2018-07-12 13:34 ` David Allsopp [this message]
2018-07-12 16:35 ` David Allsopp
2018-07-12 18:24 ` Corinna Vinschen
2018-07-10 17:12 ` Brian Inglis
2018-07-10 20:25 ` David Allsopp
2018-07-10 21:50 ` Andrey Repin
2018-07-11 8:14 ` Corinna Vinschen
2018-07-11 12:34 ` David Allsopp
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E51C5B015DBD1348A1D85763337FB6D901ADB51D5E@Remus.metastack.local \
--to=david.allsopp@cl.cam.ac.uk \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).