| 1 |
On 04/20/2016 09:01 PM, Anthony G. Basile wrote: |
| 2 |
> On 4/20/16 2:17 PM, Mike Frysinger wrote: |
| 3 |
>> On 20 Apr 2016 21:01, Alon Bar-Lev wrote: |
| 4 |
>>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote: |
| 5 |
>>>> |
| 6 |
>>>> Comments? |
| 7 |
>>> |
| 8 |
>>> You should be able to achieve similar behavior by looking at libc |
| 9 |
>>> and/or CHOST without introducing new USE flag, just like we do for |
| 10 |
>>> aix/solaris/freebsd etc... |
| 11 |
>> |
| 12 |
>> agreed ... we have kernel_Winnt & elibc_Winnt already. i think |
| 13 |
>> those represent a mingw environment (vs a cygwin env). |
| 14 |
|
| 15 |
Nope: We have used kernel_Winnt and elibc_Winnt for the native MS |
| 16 |
Visual Studio compiler, wrapped with Parity[1] to provide a gcc-like |
| 17 |
commandline interface for the toolchain. Independent of Parity I've |
| 18 |
seen traces of native cl.exe/lib.exe support within libtool as well. |
| 19 |
|
| 20 |
[1] https://github.com/haubi/parity |
| 21 |
|
| 22 |
> The way I think of it is |
| 23 |
> |
| 24 |
> the operating system (ie kernel) = kernel_Winnt |
| 25 |
> the system libraries (=~libc) = elibc_Winnt |
| 26 |
> the executable binary format = win32 |
| 27 |
|
| 28 |
Right now, for kernel_Winnt, in the prefix/windows profiles we have: |
| 29 |
|
| 30 |
+ elibc_Interix |
| 31 |
. runtime environment: Interix libc, CHOST=i586-pc-interixN.N |
| 32 |
. python+bash+portage: yes |
| 33 |
. accessible API (UI): POSIX (X11 client) |
| 34 |
. executable format : PE32 executable for MS Windows (POSIX) Intel 80386 32-bit |
| 35 |
. compiler: GNU gcc |
| 36 |
. used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winntN.N (non-cross) |
| 37 |
. state : dead, but in production here |
| 38 |
|
| 39 |
+ elibc_Winnt (32bit only for now) |
| 40 |
. runtime environment: MSVCRT, CHOST=i586-pc-winntN.N |
| 41 |
. python+bash+portage: no |
| 42 |
. accessible API (UI): Win32 (Win32) |
| 43 |
. executable format : PE32 executable for MS Windows ({console,GUI}) Intel 80386 32-bit |
| 44 |
. compiler: MSVC cl.exe (wrapped by Parity) |
| 45 |
. used as : runtime environment for my company's application |
| 46 |
. state : old, in production here, to be updated |
| 47 |
|
| 48 |
+ elibc_Cygwin |
| 49 |
. runtime environment: newlib (Cygwin), CHOST={i686,x86_64}-pc-cygwin |
| 50 |
. python+bash+portage: yes |
| 51 |
. accessible API (UI): POSIX (X11 client), Win32 (Win32) |
| 52 |
. executable format : PE32 executable ({console,GUI}) Intel 80386, for MS Windows |
| 53 |
PE32+ executable ({console,GUI}) x86_64, for MS Windows |
| 54 |
. compiler: GNU gcc |
| 55 |
. used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winnt (non-cross) |
| 56 |
build environment for elibc_Mingw: CBUILD=CHOST={i686,x86_64}-w64-mingw32 (non-cross) |
| 57 |
. state : under construction, cygwin fork patch necessary (upstream review pending) |
| 58 |
|
| 59 |
|
| 60 |
For MinGW, IMHO it feels more straightforward to add something like: |
| 61 |
|
| 62 |
+ elibc_Mingw (mingw-w64.org I guess, not mingw.org) |
| 63 |
. runtime environment: MinGW-W64, CHOST={i686,x86_64}-w64-mingw32 |
| 64 |
. python+bash+portage: no |
| 65 |
. accessible API (UI): Win32 (Win32) |
| 66 |
. executable format : PE32 executable ({console,GUI}) Intel 80386, for MS Windows |
| 67 |
PE32+ executable ({console,GUI}) x86_64, for MS Windows |
| 68 |
. compiler: GNU gcc |
| 69 |
. used as : runtime environment for various applications |
| 70 |
. state : proposal |
| 71 |
|
| 72 |
> I don't know that we need an executable binary format flag, but we might |
| 73 |
> because they're working on windows 10 so it can natively run ELF. |
| 74 |
|
| 75 |
Well, nope: |
| 76 |
Although Windows Desktop (only, not Windows Server) can run ELF somewhat "natively", |
| 77 |
it is not possible to start Windows executables from within a Linux executable. |
| 78 |
This makes me assume there is no access to the Win32 API from within Linux either. |
| 79 |
Also, they explicitly focus on the commandline only, not the GUI. |
| 80 |
|
| 81 |
So WSL (Windows Subsystem for Linux) does not seem to be useable as replacement for |
| 82 |
any of these currently possible non-crosscompiling setups: |
| 83 |
* Interix/Cygwin building Winnt (.exe runs natively) |
| 84 |
* Interix/Cygwin building Mingw (.exe runs natively) |
| 85 |
* Linux building Mingw (.exe runs in Wine) |
| 86 |
|
| 87 |
For the USE flag: |
| 88 |
As Cygwin allows for both X11 and Win32 UI, I do see fit for an additional "win32ui" |
| 89 |
or similar (win32gui, w32ui, w32gui, winui, wingui, wntui, wntgui) USE flag. |
| 90 |
|
| 91 |
And what about the new "win8ui" (formerly called Metro): |
| 92 |
Do/will GTK+, Qt and others support that too eventually? |
| 93 |
|
| 94 |
Probably we may end up with something like: IUSE="X aqua win32ui win8ui" |
| 95 |
|
| 96 |
My 2*2 cents, |
| 97 |
/haubi/ |
Archives