On 21 Apr 2016 13:16, Leno Hou wrote:
> On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote:
> > On 20 Apr 2016 13:52, Leno Hou wrote:
> > > Authored-by: Linda Jiang
> > > ---
> > > eclass/toolchain-binutils.eclass | 1 +
> > > 1 file changed, 1 insertion(+)
> >
> > when you submit a patch tha
On Wed, Apr 20, 2016 at 11:07 PM, Mike Frysinger wrote:
> On 20 Apr 2016 13:52, Leno Hou wrote:
> > Authored-by: Linda Jiang
> > ---
> > eclass/toolchain-binutils.eclass | 1 +
> > 1 file changed, 1 insertion(+)
>
> when you submit a patch that is not extremely obvious, you must provide
> detai
> On Apr 20, 2016, at 6:51 PM, Andrew Udvare wrote:
>
>> On 20/04/16 12:58, Ian Stakenvicius wrote:
>> On 20/04/16 03:41 PM, Anthony G. Basile wrote:
According to 'file' the binary format is actually "PE32 executable
(console) Intel 80386, for MS Windows" for a random *.exe file in my
On 20/04/16 12:58, Ian Stakenvicius wrote:
> On 20/04/16 03:41 PM, Anthony G. Basile wrote:
>>> According to 'file' the binary format is actually "PE32 executable
>>> (console) Intel 80386, for MS Windows" for a random *.exe file in my
>>> /usr/i686-w64-mingw32/usr/bin
That is because Mingw is for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Göktürk Yüksek:
> + + Allow concurrent
> installation of sys-boot/grub:0 and +
> sys-boot/grub:2 by renaming all programs. +
>
Please do not merge. I just realized that the slot operators
On 20/04/16 03:41 PM, Anthony G. Basile wrote:
> On 4/20/16 3:30 PM, Ian Stakenvicius wrote:
>> On 20/04/16 03:01 PM, Anthony G. Basile wrote:
>>
>>> The way I think of it is
>>
>>> the operating system (ie kernel) = kernel_Winnt the system
>>> libraries (=~libc)= elibc_Winnt the executable bin
On 4/20/16 3:30 PM, Ian Stakenvicius wrote:
> On 20/04/16 03:01 PM, Anthony G. Basile wrote:
>
>> 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
>
>> I don't know that we need
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/20/2016 02:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent
> Fredric:
>> On 21 April 2016 at 06:38, Ian Stakenvicius
>> wrote:
>>> Well so far the only needs I have run into for the win32 flag
>>>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/04/16 03:01 PM, Anthony G. Basile wrote:
>
> 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
>
> I don't know that we need a
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/04/16 03:18 PM, Mart Raudsepp wrote:
> Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent
> Fredric:
>> On 21 April 2016 at 06:38, Ian Stakenvicius
>> wrote:
>>> Well so far the only needs I have run into for the win32 flag
>>> has bee
Ühel kenal päeval, N, 21.04.2016 kell 06:53, kirjutas Kent Fredric:
> On 21 April 2016 at 06:38, Ian Stakenvicius wrote:
> > Well so far the only needs I have run into for the win32 flag has
> > been in relation to choosing UI toolkit support for cairo and gtk+
> > (and possibly others in the futu
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
On 21 April 2016 at 06:38, Ian Stakenvicius wrote:
> Well so far the only needs I have run into for the win32 flag has
> been in relation to choosing UI toolkit support for cairo and gtk+
> (and possibly others in the future), which is why I saw the parallel.
Given you're not using the flag to i
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/04/16 02:22 PM, M. J. Everitt wrote:
> On 20/04/16 19:17, Mike Frysinger wrote:
>> agreed ... we have kernel_Winnt & elibc_Winnt already. i
>> think those represent a mingw environment (vs a cygwin env).
> Surely 'winnt' is a somewhat out-of-d
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 20/04/16 02: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:
>>> After doing some experimentation with a mingw crossdev, I
>>> found that I needed to do a lot of EXTRA_E
On 20/04/16 19:17, Mike Frysinger wrote:
> agreed ... we have kernel_Winnt & elibc_Winnt already. i think
> those represent a mingw environment (vs a cygwin env).
Surely 'winnt' is a somewhat out-of-date and potentially confusing flag?
Can't we migrate to a win32 and win64 as pertaining to current
On 20 Apr 2016 21:01, Alon Bar-Lev wrote:
> On 20 April 2016 at 18:52, Ian Stakenvicius wrote:
> > After doing some experimentation with a mingw crossdev, I found that I
> > needed to do a lot of EXTRA_ECONF settings in combination with
> > USE="aqua" in order to get packages supporting a win32 API
On 20 April 2016 at 18:52, Ian Stakenvicius wrote:
>
> Hi everyone:
>
> After doing some experimentation with a mingw crossdev, I found that I
> needed to do a lot of EXTRA_ECONF settings in combination with
> USE="aqua" in order to get packages supporting a win32 API to be
> configured appropriat
Hi everyone:
After doing some experimentation with a mingw crossdev, I found that I
needed to do a lot of EXTRA_ECONF settings in combination with
USE="aqua" in order to get packages supporting a win32 API to be
configured appropriately. In order to support this situation better,
I propose adding
On 20 Apr 2016 13:52, Leno Hou wrote:
> Authored-by: Linda Jiang
> ---
> eclass/toolchain-binutils.eclass | 1 +
> 1 file changed, 1 insertion(+)
when you submit a patch that is not extremely obvious, you must provide
details/justification in the commit message. otherwise we're forced to
try an
On Wed, Apr 20, 2016 at 08:57:52AM +0200, Michał Górny wrote:
> Just FYI, we're talking about upstream maintainer elements which do not take
> part in bug assignment.
Ah, yes, I missed that; though it may have been done as something related to
that - just putting it out there.
Cheers;
--
Sam Jo
21 matches
Mail list logo
