On 11/04/2013 21:42, Thomas Wolff wrote:
> Am 11.04.2013 14:34, schrieb Dave Korn:
>> Also, I don't plan on doing it unless there's significant demand.
> I would appreciate to keep it as gcc-3.
Fancy being the maintainer for it then? ;-)
> The reason is quite peculiar; gcc-4
> changed the orde
On 12/04/2013 00:28, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:32, Dave Korn wrote:
>> On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
>>> Also in the 4.8 branch is a patch to unversion the LTO plugin; it
>>> applies to 4.7 as well.
>>
>> I'll take a look for that. Does it really matter? I don'
On 12/04/2013 00:36, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 07:35, Dave Korn wrote:
>> On 11/04/2013 13:22, NightStrike wrote:
>>> Speaking of which.. 4.8 is out...
>
> So is GNOME 3.8.0, but I tend to let others deal with the early bugs and
> catch up by .1 or even .2.
>
>> Point.
On 4/11/2013 6:08 PM, Yaakov (Cygwin/X) wrote:
On 2013-04-11 11:56, Ken Brown wrote:
/usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains
typedef long INT32
Aside from the fact that this produces a confusing name for a 64-bit
data type
Per the comment there: "INT32 must hold *at
On 2013-04-11 07:35, Dave Korn wrote:
On 11/04/2013 13:22, NightStrike wrote:
Speaking of which.. 4.8 is out...
So is GNOME 3.8.0, but I tend to let others deal with the early bugs and
catch up by .1 or even .2.
Point. Anyone got any particular preference whether I go for a 4
On 2013-04-11 07:32, Dave Korn wrote:
On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
Also in the 4.8 branch is a patch to unversion the LTO plugin; it applies
to 4.7 as well.
I'll take a look for that. Does it really matter? I don't suppose we need
support swapping LTO plugins between diff
On 2013-04-11 07:37, Charles Wilson wrote:
#1) Is it possible to also record cygwin-specific README content within
the cygport(5)? [1] If so, can you do more than one? (I'm thinking here
of inetutils, which has a separate cygwin-specific README for the
-server (sub)package and for the -client (su
On 2013-04-11 11:56, Ken Brown wrote:
/usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains
typedef long INT32
Aside from the fact that this produces a confusing name for a 64-bit
data type
Per the comment there: "INT32 must hold *at least* signed 32-bit values"
(emphasis mine).
Test packages built with gcc-4.7.2-2, TLS is enabled and finally passing
all tests for MPFR. I would appreciate if someone could check if the
setup.hint files are correct before I send an RFU (or if I should omit
them). If there's anything else I should change or check before RFU,
please let me
Am 11.04.2013 14:34, schrieb Dave Korn:
On 11/04/2013 13:19, Corinna Vinschen wrote:
On 2013-04-11 01:02, Dave Korn wrote:
Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was using
it and wants to know where it's gone. (I suppose if that happens I could
always consider ro
/usr/include/jmorecfg.h (from libjpeg-devel-1.2.1-1) contains
typedef long INT32
Aside from the fact that this produces a confusing name for a 64-bit
data type, it conflicts with /usr/include/w32api/basetsd.h, which has
typedef signed int INT32
This causes a problem for the build of emac
While the mirror script pulls down the shiny new gcc from Dave…
Charles Wilson writes:
> #1) Is it possible to also record cygwin-specific README content
> within the cygport(5)? [1] If so, can you do more than one? (I'm
> thinking here of inetutils, which has a separate cygwin-specific
> README f
On Apr 11 12:16, Corinna Vinschen wrote:
> On Apr 10 18:16, Corinna Vinschen wrote:
> > On Apr 10 16:49, Dave Korn wrote:
> > > On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
> > >
> > > > Could you explain the necessity of the dllimport's in the same patch?
> > >
> > > The idea is to one day be
On 4/11/2013 2:58 AM, Yaakov (Cygwin/X) wrote:
Something else you missed: cygport supports a new, unversioned file
format, and creates setup.hint files, including dependency detection. I
suggest using git master right now.
I know that cygwin-specific READMEs are now no longer required or
expe
On 11/04/2013 13:22, NightStrike wrote:
> Speaking of which.. 4.8 is out...
Point. Anyone got any particular preference whether I go for a 4.7.3 or
4.8.0 release next? Maybe do a 4.7.3 curr: and then a 4.8.0 test: package?
cheers,
DaveK
On 11/04/2013 13:19, Corinna Vinschen wrote:
On 2013-04-11 01:02, Dave Korn wrote:
> Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
> using
> it and wants to know where it's gone. (I suppose if that happens I could
> always consider rolling a gcc3 pa
On 11/04/2013 07:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
>> Yes, I've looked at most of your patches already, I'm not saying there's
>> any complication in adding them, it's just that I didn't want to wait
>> another howevermany days before getting 4.7.2-2 out there. I
On Thu, Apr 11, 2013 at 2:19 AM, Corinna Vinschen wrote:
> On Apr 11 13:14, Dave Korn wrote:
>> On 11/04/2013 11:13, Corinna Vinschen wrote:
>> > On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
>> >> On 2013-04-11 01:02, Dave Korn wrote:
>> >>> Yep, sure. *sigh*, I'm sure we'll suddenly find out that
On Apr 11 13:14, Dave Korn wrote:
> On 11/04/2013 11:13, Corinna Vinschen wrote:
> > On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
> >> On 2013-04-11 01:02, Dave Korn wrote:
> >>> Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
> >>> using
> >>> it and wants to know where it's
On 11/04/2013 11:13, Corinna Vinschen wrote:
> On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
>> On 2013-04-11 01:02, Dave Korn wrote:
>>> Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
>>> using
>>> it and wants to know where it's gone. (I suppose if that happens I could
>>>
On Apr 10 23:28, Yaakov (Cygwin/X) wrote:
> On 2013-04-10 08:16, Corinna Vinschen wrote:
> >- Does anybody know of a simple way to find out which packages in the 32
> > bit distro are actually "noarch' packages? The reason I'm asking is
> > that I'm looking for a simple way to fill up the 64 b
On Apr 10 18:16, Corinna Vinschen wrote:
> On Apr 10 16:49, Dave Korn wrote:
> > On 10/04/2013 10:57, Yaakov (Cygwin/X) wrote:
> >
> > > Could you explain the necessity of the dllimport's in the same patch?
> >
> > The idea is to one day be able to move away from having auto-import
> > enabled
On Apr 11 01:58, Yaakov (Cygwin/X) wrote:
> On 2013-04-11 01:02, Dave Korn wrote:
> > Yep, sure. *sigh*, I'm sure we'll suddenly find out that someone was
> > using
> >it and wants to know where it's gone. (I suppose if that happens I could
> >always consider rolling a gcc3 package with all -3
Hi.
I have tried to compile log4cplus (C++ logging library) on Cygwin64
with -flto GCC option. I am getting the following failure:
lto1: internal compiler error: in add_symbol_to_partition, at
lto/lto-partition.c:284
Here is a link (if Gmail does not botch it) to archive with the
minimal amount
24 matches
Mail list logo
