Ted Neward
Author, Speaker, Mentor
http://www.newardassociates.com
t: @tedneward | m: (425) 647-4526
On 4/26/17, 1:24 AM, "Erik Joelsson" <[email protected]> wrote:
Hello,
Most of my previous mail reflected experiences with the old version of
the linux subsystem from the anniversary edition of windows 10. I knew
they were working on improving it and it seems the Creators Update is
now live with those improvements, which is very interesting news to me!
That explains why running a boot jdk now works for you and why you can
run windows applications.
My comment about the limitations with environment variables was based on
last time I read the developers blog about the improvements they were
working on some months back:
https://blogs.msdn.microsoft.com/wsl/2016/10/19/windows-and-ubuntu-interoperability/
I'm not sure if that part has been fixed but it's quite possible. My
previous assumptions are clearly outdated.
If using the subsystem Ubuntu gcc toolchain, you would naturally build
linux applications. To build Windows applications, we would run the
Visual Studio toolchain like we do today. From what I can see, you
should be able to build linux binaries fine now. The challenge is
adjusting the build system to use the linux subsystem instead of cygwin
when producing windows binaries. I don't expect you to solve that for us
though. :)
/Erik
On 2017-04-26 09:45, Ted Neward wrote:
> Honestly, it’s not like I’m “expecting” much, period—this is more of a
“Hmmm, this should be possible, so let’s see….” kind of quest. ;-)
>
> However, I’m not under the illusion that something built using the Linux
subsystem is technically a Windows application—AFAIK, anything built using the gcc
chain under the Linux subsystem can only run under the Linux subsystem. I think.
(That’s part of the reason to do some of this—to experiment and find out where the
boundaries lie.)
>
> So step 1 is to figure out if I can get a JDK build going, and if
there’s simple fixes here to unblock the process. If/when it’s not an easy fix
here, then I can start talking to friends over in DevDiv inside Microsoft and try
to track down who owns the Linux chain there and what, if anything, can be done to
unblock without requiring massive engineering effort on Microsoft’s or Oracle’s
part.
>
> Bear in mind, too, that this is a part-time project, so I may end up
going about a half-dozen hours into this thing and go, “Damn, I’m outta time” and
have to drop it. Hence, the search for an easy fix. :-)
>
> (By the way, for the remainder of this email, everything is implicitly
referring to the Linux subsystem running in Windows 10.)
>
> I can say that from a Windows bash shell, I did get Java 8 working, so
long as it was installed via the apt manager inside the Linux subsystem; “sudo apt
install openjdk-8” (IIRC) worked fine, and I have a Java environment that, as far
as I can tell, runs Java just fine. (sdkman.io also works, by the way, which I
think was what I ended up doing instead of apt-get just for easier maintenance on
my end.) Getting the bootstrap JDK in place was definitely not a hard thing to do.
>
> As for running native Windows apps from the Linux subsystem, again, this
isn’t a problem so long as the right binaries are found. Here’s what I mean: By
nature, it seems that the bash shell implicitly combines both a Linux PATH
(“/usr/local/bin:/usr/bin:…”) with the surrounding Windows machine’s PATH
(“C:\Windows;C:\Windows\System32;…”) to create one long PATH with Unix-ified
paths. (The Windows file paths are transformed into Linux subsystem paths by
“mounting” drives C (and D, and E, and whatever else) under a “/mnt” directory and
proceeding as normal from there.)
>
> If I’m in a bash shell, and I type “notepad”, Linux suggests installing
WINE. If I’m in the same shell and I type “/mnt/c/Windows/notepad.exe”, then it
fires up Notepad without a hitch. I think the key thing here is that the “.exe”
part of the name is always assumed in a Windows (CMD.EXE) shell, whereas in *nix
by default you need the full name. (Just trying this out, when I type
“notepad.exe” without the path prefix in a bash shell, it works fine as well,
assuming /mnt/c/Windows is on the PATH, which it is in my bash shell by default.)
>
> So I will assert that crossing the Linux/Windows boundary may be a lot
easier than originally assumed. FWIW, in a CMD.exe shell, running “ver” tells me
I’m running Windows 10.0.15063, which I believe corresponds with the “Creators
Update” build of Win 10, if that makes a difference in your own testing.
>
> Ted Neward
> Author, Speaker, Mentor
> http://www.newardassociates.com
> t: @tedneward | m: (425) 647-4526
>
> On 4/25/17, 3:29 AM, "Erik Joelsson" <[email protected]> wrote:
>
> Hello,
>
> First of all, are you expecting to build linux or windows binaries
in
> the ubuntu subsystem? Our interest is to use it to replace cygwin
when
> producing windows binaries.
>
> In theory it should be possible to build linux binaries, but AFAIK,
> current OpenJDK linux binaries crash on startup when trying to run
> there, which prevents building since we need a bootjdk to run the
build
> (a JDK 8 boot to build JDK 9). I have not investigated this any
further,
> just a college's first impression when it was first released. If
you got
> this to work, we would likely be able to build linux binaries at
least.
> Though, while amusing, that wouldn't be particularly useful for me
at least.
>
> The next hurdle is crossing the linux/windows barrier again when
running
> native windows applications from the linux subsystem. This was not
> possible at all in the current release, but I know it's being
worked on.
> Perhaps it even works in some kind of beta at this point. From what
I've
> read about it there are some limitations which would require some
> trickery from us to get around. For example environment variables
are
> not shared between the environments.
>
> All in all this looks like very interesting for the future.
>
> /Erik
>
>
> On 2017-04-24 19:35, Ted Neward wrote:
> > Can you be more specific as to which features it’s lacking?
(Having spent a fair amount of time on Windows in my career, I might be able to
suggest some ways to work with/around it, though I’ll be the first to admit the
Linux-on-Windows subsystem is new to me. The other thing is, I live in Redmond, and I
have several friends who work on DotNetCore, and can maybe ask them for some ideas on
how to work around whatever issues that are coming up.)
> >
> > Meanwhile, I’ll see if the build works. (I’m not in front of that
machine as I write this.)
> >
> > Ted Neward
> > Author, Speaker, Mentor
> > http://www.newardassociates.com
> > t: @tedneward | m: (425) 647-4526
> >
> > On 4/24/17, 5:10 AM, "Erik Joelsson" <[email protected]>
wrote:
> >
> > Hello Ted,
> >
> > I do not recognize the error, but I suspect that the failing
command is
> > the first time the build is running the newly built jdk to
generate
> > something. Can you try this and see if that works?
> >
> > $ build/linux-x64/jdk/bin/java
> >
> > The build should work on Ubuntu 16.04 (it's what I use
personally most
> > of the time). The ubuntu shell on Win10 however is not going
to work.
> > It's certainly something we would like to leverage in the
future, but so
> > far, it's lacking vital features to be feasible.
> >
> > /Erik
> >
> > On 2017-04-24 10:41, Ted Neward wrote:
> > > Tried using Ubuntu 16 (in a Virtual Box image, if that
makes a difference) and the Ubuntu shell in Win10, and keep getting the same error:
> > >
> > >
> > >
> > > ExplodedImageOptimize.gmk:40: recipe for target
‘…/jdk_packages_attribute.done’ failed
> > >
> > >
> > >
> > > Happens for any kind of configured build (fastdebug,
slowdebug, release, tried all three). Not sure how to start debugging this. Hoping that
somebody has seen this before and has a quick one-line fix.
> > >
> > >
> > >
> > > Error messages suggest checking the build log; where is that?
(I’m guessing build/<target>/build.log, but just checking to make sure there isn’t
another one I should be looking at…)
> > >
> > >
> > >
> > > Ted Neward
> > >
> > > Author, Speaker, Mentor
> > >
> > > http://www.newardassociates.com
> > >
> > > t: @tedneward | m: (425) 647-4526
> > >
> >
> >
> >
> >
>
>
>
>
