Re: [gentoo-dev] glibc 2.23 and willfully breaking stuff
On Tue, 19 Apr 2016 19:04:47 +0200 Dirkjan Ochtman wrote: > On Apr 19, 2016 6:28 PM, "Anthony G. Basile" wrote: > > yeah we need to buy him a drink or something really. i'd say make him a > > dev but i'm not sure i'd inflict that punishment on anyone :P > > +1 make him a dev. +1 here Best regards, Andrew Savchenko pgpRwKnidiQd_.pgp Description: PGP signature
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
Ühel kenal päeval, N, 21.04.2016 kell 15:42, kirjutas Ian Stakenvicius: > b) -1 for making it global right now pending resolution of logistics > for the profiles/base/use.mask entry, I don't think it's unprecedented to just globally use.mask a USE flag even if it's not declared a global USE flag. Or more like it's common that architectures use.mask local flags used in more than one place with a clear meaning it involved a dep they don't want or can't keyword. Globally masking and unmasking in one profile is kind of similar. Those reading PMS or whatnot can speak up if needed, but I don't see a problem here. The discussion is useful, as I suspect we can get sufficient users soon enough, especially if you look into some of the other GUI stuff that can work there (e.g gitg/gedit), though the question is what's the real use of having any of these if upstream isn't looking into making use of this to build their windows binaries or whatnot. > c) rejection for the proposed ebuild patches pending a toolkit > refactoring to be determined later. Not really a rejection, it's just that I haven't looked into those patches with a review mind as of yet. It just sounds like it's worth looking at it deeper, that maybe there's more extensive improvement possibilities. So just not an ACK as of yet. > > B and C make most of this thread pretty well moot, I guess, but > following A, can we decide that USE="winapi" could be a good flag > name? If nobody objects I'll use that when leio and I work on the > refactoring of gtk+ and likely try to use local flags somehow for > now.
[gentoo-dev] Last rites: app-misc/tablix
# Michael Palimaka (21 Apr 2016) # Requires package no longer in the tree to be useful. Unmaintained. # Dead upstream. Masked for removal in 30 days. app-misc/tablix
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
On 21/04/16 11:31 AM, Mart Raudsepp wrote: > Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp: >> Basically the only real point I have is that anything kernel_* to >> control this probably doesn't make sense. >> > > Oh, just to clarify and avoid misunderstanding: > I did not intend to ack the changes to gdk-pixbuf and gtk+ with my > message, even if the flag name is changed. > It sounds to me like we have some refactoring to do in those ebuilds > together with aqua in mind as well, once we have agreed on the future > global USE flag name. > I also vote 'no' to the profiles changes, because we don't have 6+ > packages with the flag yet to make it global use flag quite yet (though > it would make sense once we do, and in essence it is a global one that > needs masking in other profiles, etc - fiddly with local use flag). > > Once this thread has concluded on a naming, I'm sure we can have a > productive gtk/gdk-pixbuf review via IRC :) > > > Mart > Ok, so to summarize: a) +1 for a USE flag instead of KERNEL/ELIBC (that's 4 in favour, 2 against i think?) b) -1 for making it global right now pending resolution of logistics for the profiles/base/use.mask entry, c) rejection for the proposed ebuild patches pending a toolkit refactoring to be determined later. B and C make most of this thread pretty well moot, I guess, but following A, can we decide that USE="winapi" could be a good flag name? If nobody objects I'll use that when leio and I work on the refactoring of gtk+ and likely try to use local flags somehow for now. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] RFC: new USE="win32" flag for mingw and prefix/windows support
Ühel kenal päeval, K, 20.04.2016 kell 22:18, kirjutas Mart Raudsepp: > Basically the only real point I have is that anything kernel_* to > control this probably doesn't make sense. > Oh, just to clarify and avoid misunderstanding: I did not intend to ack the changes to gdk-pixbuf and gtk+ with my message, even if the flag name is changed. It sounds to me like we have some refactoring to do in those ebuilds together with aqua in mind as well, once we have agreed on the future global USE flag name. I also vote 'no' to the profiles changes, because we don't have 6+ packages with the flag yet to make it global use flag quite yet (though it would make sense once we do, and in essence it is a global one that needs masking in other profiles, etc - fiddly with local use flag). Once this thread has concluded on a naming, I'm sure we can have a productive gtk/gdk-pixbuf review via IRC :) Mart
[gentoo-dev] Re: RFC: new USE="win32" flag for mingw and prefix/windows support
On 04/20/2016 09:01 PM, Anthony G. Basile wrote:
> On 4/20/16 2:17 PM, Mike Frysinger wrote:
>> On 20 Apr 2016 21:01, Alon Bar-Lev wrote:
>>> On 20 April 2016 at 18:52, Ian Stakenvicius wrote:
Comments?
>>>
>>> You should be able to achieve similar behavior by looking at libc
>>> and/or CHOST without introducing new USE flag, just like we do for
>>> aix/solaris/freebsd etc...
>>
>> agreed ... we have kernel_Winnt & elibc_Winnt already. i think
>> those represent a mingw environment (vs a cygwin env).
Nope: We have used kernel_Winnt and elibc_Winnt for the native MS
Visual Studio compiler, wrapped with Parity[1] to provide a gcc-like
commandline interface for the toolchain. Independent of Parity I've
seen traces of native cl.exe/lib.exe support within libtool as well.
[1] https://github.com/haubi/parity
> The way I think of it is
>
> the operating system (ie kernel) = kernel_Winnt
> the system libraries (=~libc)= elibc_Winnt
> the executable binary format = win32
Right now, for kernel_Winnt, in the prefix/windows profiles we have:
+ elibc_Interix
. runtime environment: Interix libc, CHOST=i586-pc-interixN.N
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client)
. executable format : PE32 executable for MS Windows (POSIX) Intel 80386
32-bit
. compiler: GNU gcc
. used as : build environment for elibc_Winnt:
CBUILD=CHOST=i586-pc-winntN.N (non-cross)
. state : dead, but in production here
+ elibc_Winnt (32bit only for now)
. runtime environment: MSVCRT, CHOST=i586-pc-winntN.N
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format : PE32 executable for MS Windows ({console,GUI}) Intel
80386 32-bit
. compiler: MSVC cl.exe (wrapped by Parity)
. used as : runtime environment for my company's application
. state : old, in production here, to be updated
+ elibc_Cygwin
. runtime environment: newlib (Cygwin), CHOST={i686,x86_64}-pc-cygwin
. python+bash+portage: yes
. accessible API (UI): POSIX (X11 client), Win32 (Win32)
. executable format : PE32 executable ({console,GUI}) Intel 80386, for MS
Windows
PE32+ executable ({console,GUI}) x86_64, for MS
Windows
. compiler: GNU gcc
. used as : build environment for elibc_Winnt: CBUILD=CHOST=i586-pc-winnt
(non-cross)
build environment for elibc_Mingw:
CBUILD=CHOST={i686,x86_64}-w64-mingw32 (non-cross)
. state : under construction, cygwin fork patch necessary (upstream
review pending)
For MinGW, IMHO it feels more straightforward to add something like:
+ elibc_Mingw (mingw-w64.org I guess, not mingw.org)
. runtime environment: MinGW-W64, CHOST={i686,x86_64}-w64-mingw32
. python+bash+portage: no
. accessible API (UI): Win32 (Win32)
. executable format : PE32 executable ({console,GUI}) Intel 80386, for MS
Windows
PE32+ executable ({console,GUI}) x86_64, for MS
Windows
. compiler: GNU gcc
. used as : runtime environment for various applications
. state : proposal
> I don't know that we need an executable binary format flag, but we might
> because they're working on windows 10 so it can natively run ELF.
Well, nope:
Although Windows Desktop (only, not Windows Server) can run ELF somewhat
"natively",
it is not possible to start Windows executables from within a Linux executable.
This makes me assume there is no access to the Win32 API from within Linux
either.
Also, they explicitly focus on the commandline only, not the GUI.
So WSL (Windows Subsystem for Linux) does not seem to be useable as replacement
for
any of these currently possible non-crosscompiling setups:
* Interix/Cygwin building Winnt (.exe runs natively)
* Interix/Cygwin building Mingw (.exe runs natively)
* Linux building Mingw (.exe runs in Wine)
For the USE flag:
As Cygwin allows for both X11 and Win32 UI, I do see fit for an additional
"win32ui"
or similar (win32gui, w32ui, w32gui, winui, wingui, wntui, wntgui) USE flag.
And what about the new "win8ui" (formerly called Metro):
Do/will GTK+, Qt and others support that too eventually?
Probably we may end up with something like: IUSE="X aqua win32ui win8ui"
My 2*2 cents,
/haubi/
