> Dennis Clarke writes:
>
>>> The only caveat are strange errors with gmake:
>>>
>>> make[3]: write error
>>>
>>> See CR 6938116 GNU make highly unreliable: `write error' message.
>>>
>>> I've hacked around this by ignoring the error in misc.c (close_stdout)
>>> ;-)
>>>
>>
>> It seems odd th
Dennis Clarke writes:
>> The only caveat are strange errors with gmake:
>>
>> make[3]: write error
>>
>> See CR 6938116 GNU make highly unreliable: `write error' message.
>>
>> I've hacked around this by ignoring the error in misc.c (close_stdout) ;-)
>>
>
> It seems odd that gmake would pa
> Dennis Clarke writes:
>
>> Do you know if anyone has ever tested that on Solaris ? Lately Solaris
>> is
>> where open source goes to die ( blame Larry for that ) so I figure I may
>> as well give it a shot, but before I do .. tell me know if this little
>> trick works at all.
>
> Why shouldn't
Dennis Clarke writes:
> Do you know if anyone has ever tested that on Solaris ? Lately Solaris is
> where open source goes to die ( blame Larry for that ) so I figure I may
> as well give it a shot, but before I do .. tell me know if this little
> trick works at all.
Why shouldn't it? I'm using
> On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote:
>> Ryan Hill writes:
>>
>> > Does anyone know since when (if) running make check with more than one
>> job
>> > has been supported? IIRC back in the 3.x days it caused issues so
>> we've
>> > been forcing -j1 here forever. If w
On Wed, Mar 30, 2011 at 11:45:38PM -0700, Ian Lance Taylor wrote:
> Ryan Hill writes:
>
> > Does anyone know since when (if) running make check with more than one job
> > has been supported? IIRC back in the 3.x days it caused issues so we've
> > been forcing -j1 here forever. If we could run i
Ryan Hill writes:
> Does anyone know since when (if) running make check with more than one job
> has been supported? IIRC back in the 3.x days it caused issues so we've
> been forcing -j1 here forever. If we could run it in parallel that would be a
> big timesaver.
Jakub fixed it back in 2008
On Tue, 29 Mar 2011 12:29:13 -0400
NightStrike wrote:
> On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn
> wrote:
> > True but takes rather a long time on a cygwin host that's already running
> > "make -j8 check"! So I asked. Apologies for minor laziness, hope you
> > didn't
> > feel /obligated/
On 03/30/2011 09:10 AM, Bernd Roesch wrote:
> I add an error in file libiberty/pex-win32.c to check if cygwin build use
> win32_spawn.
That's because it doesn't use pex-win32.c.
> I add now an error in pex_unix.c, and compile file.so cygwin build use vfork
> stuff.
You need to look more carefu
Bernd Roesch writes:
> I add an error in file libiberty/pex-win32.c to check if cygwin build use
> win32_spawn.
> but gcc compile ok, so it seem that cygwin build do not use pex-win32.c.Or
> need i set a compile
> option for GCC ?
The choice is determined in libiberty/configure.ac:
*-*-m
Hello
On 29.03.11, you wrote:
>>
>> This sounds like the generic Cygwin fork-error/BLODA problem and not
>> specific to GCC.
>
> Indeed. For what it's worth, gcc itself *does* use the Cygwin spawn*
> functions
> to avoid this problem, but (curiously) the Cygwin versions of make, bash, and
On 03/29/2011 05:53 AM, Dave Korn wrote:
>> I think it can too in readme add that on current cygwin on win 64 and
>> multicore CPU GCC compile lots slower as on single CPU systems. To speed up
>> GCC and compile 3* faster in windows taskmanager can the CPU number set to
>> 1 for the shell task.
>>
On Tue, Mar 29, 2011 at 10:45 AM, Dave Korn wrote:
> On 29/03/2011 15:32, Jakub Jelinek wrote:
>> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote:
>>> On 28/03/2011 08:25, Jakub Jelinek wrote:
The GNU Compiler Collection version 4.6.0 has been released.
>>> Were there any changes
On 29/03/2011 15:32, Jakub Jelinek wrote:
> On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote:
>> On 28/03/2011 08:25, Jakub Jelinek wrote:
>>> The GNU Compiler Collection version 4.6.0 has been released.
>> Were there any changes (other than perhaps repackaging) after the second RC
>> (d
On Tue, Mar 29, 2011 at 03:13:07PM +0100, Dave Korn wrote:
> On 28/03/2011 08:25, Jakub Jelinek wrote:
> > The GNU Compiler Collection version 4.6.0 has been released.
>
> Were there any changes (other than perhaps repackaging) after the second RC
> (dated 20110321)?
You can easily look at svn.
On 28/03/2011 08:25, Jakub Jelinek wrote:
> The GNU Compiler Collection version 4.6.0 has been released.
Were there any changes (other than perhaps repackaging) after the second RC
(dated 20110321)?
cheers,
DaveK
On 29/03/2011 09:50, Bernd Roesch wrote:
> Hello
>
> On 28.03.11, you wrote:
>
>> I think that the right place for the note is at
>>
>> http://gcc.gnu.org/install/specific.html#x-x-cygwin
>>
>> It should say something like:
>>
>> Versions of Cygwin older than x.y.z fail to build the decimal fl
On 28/03/2011 19:52, FX wrote:
>> this is a known issue and strictly cygwin related. Please update your
>> cygwin environment to newest version, or disable decimal-floating
>> point by option.
>
> Well, maybe this is known, but it is not noted on the GCC 4.6.0 release
> notes, nor on the target-s
Hello
On 28.03.11, you wrote:
>
> I think that the right place for the note is at
>
> http://gcc.gnu.org/install/specific.html#x-x-cygwin
>
> It should say something like:
>
> Versions of Cygwin older than x.y.z fail to build the decimal floating
> point library, libbid. You will either nee
On Mon, Mar 28, 2011 at 11:52:56AM -0700, FX wrote:
> > this is a known issue and strictly cygwin related. Please update your
> > cygwin environment to newest version, or disable decimal-floating
> > point by option.
>
> Well, maybe this is known, but it is not noted on the GCC 4.6.0 release
> no
> this is a known issue and strictly cygwin related. Please update your
> cygwin environment to newest version, or disable decimal-floating
> point by option.
Well, maybe this is known, but it is not noted on the GCC 4.6.0 release notes,
nor on the target-specific installation information page at
2011/3/28 Piotr Wyderski :
> Jakub Jelinek :
>
>> The GNU Compiler Collection version 4.6.0 has been released.
>
> Compilation failure on Cygwin:
>
> ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error:
> fenv.h:
> No such file or directory
> compilation terminated.
> make[3]: *
Jakub Jelinek :
> The GNU Compiler Collection version 4.6.0 has been released.
Compilation failure on Cygwin:
../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h:
No such file or directory
compilation terminated.
make[3]: *** [bid_decimal_globals.o] Error 1
Configured
--
123456789+123456789+123456789+123456789+123456789+123456789+1234
MESSAGE ENDS ----------
Original Message
Subject: GCC 4.6.0 Released
From:&qu
The GNU Compiler Collection version 4.6.0 has been released.
GCC 4.6.0 is a major release, containing substantial new functionality
not available in GCC 4.5.x or previous GCC releases.
The "link-time optimization" framework introduced in GCC 4.5.0 has been
significantly improved in this release,
25 matches
Mail list logo
