[Scons-users] Windows Subsystem for Linux (WSL) with SCons for cross-compiling

[Bill Deegan]

I'd argue this is not really a cross compile.

wsl <command>
is really not different than
ssh user at host -c "<command>"

Which would be unwise (in almost every case) to do in the case the
filesystem isn't shared.


On Thu, Jun 20, 2019 at 9:03 AM Jason Kenny <dragon512 at live.com> wrote:

> What you are wanting to do is cross windows build on Linux. That is what
> the x86_64-w64-mingw32-g++ tool is doing for you. You happen to be doing
> a cross windows build on linux on a windows box via the WSL.
>
> there is two way for you to go forward on this.
>
> 1) install python/SCons on the WSL and use it  ( do a window cross build
> on linux )
> 2) install Mingw on windows and use it with a windows install of python
> and scons  (do a native windows build with gcc)
>
> I think part of the confusion is that the WSL is a sub-system on windows (
> ie a system within a system that does not require a VM to run). The only
> real difference with WSL1 and WSL2 will be that we will have a full Linux
> kernel running and mapped to the windows kernel, vs partial emulation. This
> will allow the user to run many different versions of Linux on windows at
> the same time. Hopefully, the rest of the issues I have seen such as
> network/port emulation on /dev will be fixed.  This does not make a windows
> box a Linux system. When running under the WSL you have to install
> everything you want the WSL instance to use. windows tools do not work in
> the wsl and Linux tools only see the windows file system through what is
> basically a samba mount
>
> You are having Scons invoke the default wsl instance to do a command (such
> as GCC ) from within the WSL. This is really no different than having SCons
> call gcc through docker. The main issue here is the scons does not see what
> is in the docker image on the windows side ( same with WSL). Because of
> this, it cannot configure itself correctly
>
> Jason
> ------------------------------
> *From:* Scons-users <scons-users-bounces at scons.org> on behalf of
> damien at khubla.com <damien at khubla.com>
> *Sent:* Thursday, June 20, 2019 10:28 AM
> *To:* 'SCons users mailing list'
> *Subject:* Re: [Scons-users] Windows Subsystem for Linux (WSL) with SCons
> for cross-compiling
>
> -----Original Message-----
> From: Scons-users <scons-users-bounces at scons.org> On Behalf Of Mats
> Wichmann
> Sent: Thursday, June 20, 2019 9:18 AM
> To: SCons users mailing list <scons-users at scons.org>; Bill Deegan <
> bill at baddogconsulting.com>
> Doesn't WSL2 fix this with a real Linux subsystem all the way down? We ran
> into the same problems with WSL 1, but we do actual Linux builds anyway so
> it didn't really impact us, it was just for convenience.
>
> Damien
>
> Subject: Re: [Scons-users] Windows Subsystem for Linux (WSL) with SCons
> for cross-compiling
>
> On 6/20/19 8:56 AM, Bill Deegan wrote:
> > I"m going to agree with Jason.
> ...
> > SCons interrogates the system it's on to decide about initializing
> > various tools. To get scons to think it's on a linux system when it
> > does such on a windows system, but only for one Environment() would be
> > likely way more work than it's worth.
> >
> > BTW - Mats - I wouldn't consider this really cross building as it's
> > really building on linux from windows.  And it's not that bad to setup.
> > Of course pull request to make it easier to cross compile and/or
> > docs/wiki pages always welcome.. ;)
>
> Well, it kinda is:  scons running in the windows context to run commands
> which are running in the linux context.  But yeah, it's not the classical
> case, which I don't know how to fix or I would have done it for IoTivity
> (of course I knew much much less about scons then!).
>
> But I think this was really the crux of it: if it's Windows scons,
> everything it finds is going to be in the Windows filesystem, then you try
> to run actions which are going to need tools in the Linux container
> - and last I knew Microsoft still said there wasn't support for Windows
> commands looking at files inside the Linux environment (although it works
> the other direction).
>
> So scons will have detected all the wrong stuff.
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C2e81a6dc5190499a38ba08d6f5940b61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636966413524642342&sdata=NFSvrknBedkPe1YS4dNrhPMU7VbpbykKdRluFpmXMr4%3D&reserved=0
>
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
>
> https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpairlist4.pair.net%2Fmailman%2Flistinfo%2Fscons-users&data=02%7C01%7C%7C2e81a6dc5190499a38ba08d6f5940b61%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636966413524642342&sdata=NFSvrknBedkPe1YS4dNrhPMU7VbpbykKdRluFpmXMr4%3D&reserved=0
> _______________________________________________
> Scons-users mailing list
> Scons-users at scons.org
> https://pairlist4.pair.net/mailman/listinfo/scons-users
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pairlist4.pair.net/pipermail/scons-users/attachments/20190620/edb13da7/attachment-0001.html>