Hi,
On Tuesday 28 February 2006 22:30, René Rebe wrote:
> Hi,
>
> On Tuesday 28 February 2006 20:54, Mark Mitchell wrote:
>
> > > gxx_include_dir = $(libsubdir)/include/c++
> >
> > That's the problem, then; there's no definition of libsubdir in that
> > Makefile. What happens if you provide th
Hi all,
I'm designing a new hardware that needs to know which GPR contains a
simple integer, and which contained pointer. The hardware simply needs
different load operations for both (we're talking load/store machines,
with no indirect addressing to make life easier).
From the compiler's per
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Yours,
Eric.
On Mar 1, 2006, at 1:43 AM, Eric Fisher wrote:
Hi,
After talking about mips-elf, mips-linux, mips-elf-linux-gnu, my
friend told that there is also a target of mips-linux-elf. My God,
confused.
Ignore your friend.
-eric
Eric Botcazou <[EMAIL PROTECTED]> writes:
[...]
| Comments?
Go for it!
-- Gaby
Andrew Pinski writes:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I'll have a try now.
Andrew.
Jeffrey A Law wrote:
> I wouldn't have a problem with non-canonical bounds if there were
> no way to get a value into an object which is outside the
> bounds. But if we can get values into the object which are outside
> those bounds, then either the bounds are incorrect or the program
> is invali
Hi,
I have a problem with the compiler gcc 3.4.4.
With the gcc 3.2 compiler, i have no problem with the following instruction :
creal(U0[i])=PartieReelle;
cimag(U0[i])=PartieImaginaire;
Now with the gcc 3.4.4 i have the folowing message :
-- erreur: invalid lvalue
Andrew Haley writes:
> Andrew Pinski writes:
> > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > for running gij to fail. Does anyone know what is going on here?
>
> I'll have a try now.
You are right. The error is
lt-gij: relocation error:
/home/aph/gcc/trun
On Tue, 2006-02-28 at 18:59 -0500, Daniel Jacobowitz wrote:
> On Tue, Feb 28, 2006 at 03:40:37PM -0700, Jeffrey A Law wrote:
> > Here's a great example from uintp.adb (which is the cause of the
> > testsuite hang FWIW)
> >
> > We have a loop with the following termination code in uintp.num_bits
>
On Mar 1, 2006, at 2:43 AM, Maurizio Loreti wrote:
/usr/soft/lib/libmpfr.a(set_str.o): In function `mpfr_set_str':
set_str.c:(.text+0x174): undefined reference to `__ctype_b'
set_str.c:(.text+0x3b5): undefined reference to `__ctype_b'
set_str.c:(.text+0x411): undefined reference to `__ctype_b'
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Indeed, having looked a bit closer at Uintp, I think this is the right fix.
Robert, please confirm.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:
On Mar 1, 2006, at 6:48 AM, Andrew Haley wrote:
Andrew Haley writes:
Andrew Pinski writes:
With clean sources on x86_64-linux-gnu, I am getting almost all tests
for running gij to fail. Does anyone know what is going on here?
I'll have a try now.
You are right. The error is
lt-gij: rel
So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
issue, thanks for spotting this!
Sorry, my last suggestion is clearly wrong. I think is right.
*** uintp.adb 12 Sep 2003 21:50:56 - 1.80
--- uintp.adb 1 Mar 2006 13:16:21 -
*** package b
On Wed, 1 Mar 2006, Andrew Pinski wrote:
This means your libmpfr.a was compiled for the wrong glibc.
Thanks for the hint -- now I have completed the 4.1.0 build/install, with
[EMAIL PROTECTED] 19 $ gcc -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1.0/configure
On Tue, Feb 28, 2006 at 08:40:18PM -0500, Andrew Pinski wrote:
> With clean sources on x86_64-linux-gnu, I am getting almost all tests
> for running gij to fail. Does anyone know what is going on here?
I will bet it is
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17311
H.J.
On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> Andrew Haley writes:
> > Andrew Pinski writes:
> > > With clean sources on x86_64-linux-gnu, I am getting almost all tests
> > > for running gij to fail. Does anyone know what is going on here?
> >
> > I'll have a try now.
>
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> > Andrew Haley writes:
> > > Andrew Pinski writes:
> > > > With clean sources on x86_64-linux-gnu, I am getting almost all
> > tests
> > > > for running gij to fail. Does anyone know what is going on he
On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote:
> I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the vendor
> string is picked up by my ebuild scripts to pass the iwmmxt target flags.
> Given my objective, am I wrong to try to make a tool chain that targets
> xs
Hi all,
I maintain a port of gcc for an embedded processor which has a HALT
instruction. This instruction stops the processor, and generates an
appropriate interrupt to indicate to its parent system that it has
stopped. The instruction is accessed by the programmer using a
port-specific built
>
> Hi all,
>
> I maintain a port of gcc for an embedded processor which has a HALT
> instruction. This instruction stops the processor, and generates an
> appropriate interrupt to indicate to its parent system that it has
> stopped. The instruction is accessed by the programmer using a
> por
On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 11:48:39AM +, Andrew Haley wrote:
> > > Andrew Haley writes:
> > > > Andrew Pinski writes:
> > > > > With clean sources on x86_64-linux-gnu, I am getting almost all
> tests
> >
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > >
> > > The fix was posted at
> > >
> > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html
> >
> > If it still works, please check it in.
>
> Ooops. The correct patch i
On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote:
> H. J. Lu writes:
> > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > H. J. Lu writes:
> > > >
> > > > The fix was posted at
> > > >
> > > > http://gcc.gnu.org/ml/gcc-patches/2004-09/msg01486.html
> > >
H. J. Lu writes:
> On Wed, Mar 01, 2006 at 03:19:18PM +, Andrew Haley wrote:
> > H. J. Lu writes:
> > > On Wed, Mar 01, 2006 at 02:11:21PM +, Andrew Haley wrote:
> > > > H. J. Lu writes:
> > > > >
> > > > > The fix was posted at
> > > > >
> > > > > http://gcc.gnu.org/ml/
On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote:
> On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
> > Thanks for the quick response!
> > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
> > porting Gentoo Linux to iWMMXt with pure EABI kernel and u
Hi Andrew,
The problem with calling __builtin_trap directly comes when several
traps are called in the same function. For example, if a function
contains several identical assertions on different code paths, then gcc
will generate a single copy of the assertion, and branch to that copy
from e
>My confusion is that these functions currently allow arithmetic
>operations of the form "reg = op(mem,immed)" even though this
>shape isn't supported by x86 ISA.
The IMUL instruction can have this form.
Ross Ridge
GCC 4.1.0 has been released.
This release is a major release, containing substantial new
functionality relative to previous releases. See:
http://gcc.gnu.org/gcc-4.1/changes.html
for a list of new features, improvements, and other changes.
This release is available from the FTP servers list
On Wed, 2006-03-01 at 08:15 +0100, Eric Botcazou wrote:
> Hi,
>
> I'm a big fan of Zack's "over-my-dead-body" motto when it comes to ditching
> bootstrap with non-GCC compilers. :-) It turns out that bootstrap is again
> broken on mainline for them (at least Sun CC) and that the problem is anot
>
> Hi Andrew,
>
> The problem with calling __builtin_trap directly comes when several
> traps are called in the same function. For example, if a function
> contains several identical assertions on different code paths, then gcc
> will generate a single copy of the assertion, and branch to tha
René Rebe wrote:
> As expected the headers are in the correct location now.
Good. Have you filed a bug in Bugzilla about this issue? If not, would
you care to do so? To do so, please visit gcc.gnu.org, and look for the
link on the left side of the page.
Thanks,
--
Mark Mitchell
CodeSourcery
--- Paul Brook <[EMAIL PROTECTED]> wrote:
> On Wednesday 01 March 2006 05:05, Daniel Jacobowitz wrote:
> > On Wed, Mar 01, 2006 at 04:57:03AM +, Steven Newbury wrote:
> > > Thanks for the quick response!
> > > I'm sure it seems I like to make hard wok for myself! It gets worse, I'm
> > > port
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 05:15:07AM +, Steven Newbury wrote:
> > I have managed to build with arm-iwmmxt-linux-gnu, where iwmmxt as the
> vendor
> > string is picked up by my ebuild scripts to pass the iwmmxt target flags.
> > Given my object
On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote:
> My reason for using the xscale-* triplets was because of the warning below
> from
> gcc/config/arm/t-xscale-elf:
>
> # The iWMMXt multilibs are suppressed for now because gcc only
> # supports generating them with the IWMMXT or AAP
Mark wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
> versions of tar are likely to report errors or silently unpack the
> file incorrectly.
Now hold on there, bubaloo.
I thought the warnings from older versions of tar were benign.
The warnings I'm seeing from tar-1
On Wed, Mar 01, 2006 at 10:05:52AM -0800, Dan Kegel wrote:
> Mark wrote:
> > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > versions of tar are likely to report errors or silently unpack the
> > file incorrectly.
>
> Now hold on there, bubaloo.
> I thought the warnings f
On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > versions of tar are likely to report errors or silently unpack the
> > > file incorrectly.
>
> The problem has nothing to do with warnings from tar, which are ne
On Wed, Mar 01, 2006 at 10:10:39AM -0800, Dan Kegel wrote:
> On 3/1/06, Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> > > > 1. GNU TAR 1.14 is required to unpack the source releases. Other
> > > > versions of tar are likely to report errors or silently unpack the
> > > > file incorrectly.
> >
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 05:43:53PM +, Steven Newbury wrote:
> > My reason for using the xscale-* triplets was because of the warning below
> from
> > gcc/config/arm/t-xscale-elf:
> >
> > # The iWMMXt multilibs are suppressed for now because
On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
> OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc
> and
> --disable-multilib. The vendor string is for my build scripts and also will
> help differentiate the toolchain, is that valid?
Yep.
--
Daniel Ja
Hi,
A pre-release of GCC-3.4.6 is available at
ftp://gcc.gnu.org/pub/gcc/prerelease-3.4.6-20060301/
Please download and test.
At the moment, there is only one issue I consider important for
GCC-3.4.6. This is wrong code generation issue middle-end/24804. It
was already present in
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
> 1. GNU TAR 1.14 is required to unpack the source releases. Other
>versions of tar are likely to report errors or silently unpack the
>file incorrectly.
Red Hat EL3 comes with tar 1.13.25 (though since the RPM package on the
On Wed, Mar 01, 2006 at 08:24:18AM -0800, Mark Mitchell wrote:
>
> GCC 4.1.0 has been released.
>
It is great. Is 4.1 branch open now? I'd like to back port the x86
-mtune=generic patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg01436.html
to 4.1.1.
Thanks.
H.J.
The GCC 4.1 branch is now open, under the usual branch rules: fixes for
regressions only.
Remember: the GCC 4.0 branch will freeze at midnight tonight, GMT-8, in
preparation for GCC 4.0.3.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> Is 4.1 branch open now? I'd like to back port the x86
> -mtune=generic patch:
Isn't that totally inappropriate for a release branch?
Gr.
Steven
On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > Is 4.1 branch open now? I'd like to back port the x86
> > -mtune=generic patch:
>
> Isn't that totally inappropriate for a release branch?
>
What is it inappropriate about?
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > Is 4.1 branch open now? I'd like to back port the x86
> > > -mtune=generic patch:
> >
> > Isn't that totally inappropriate fo
On Wed, Mar 01, 2006 at 09:42:19PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 09:21:19PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:14, H. J. Lu wrote:
> > > > Is 4.1 branch open now? I'd like to back port the x
> > It's a new feature and not a fix for a regression. -> totally
> > inappropriate.
>
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2. I
> can't recommond gcc 4.1 to most people using IA32/x86-64. This ch
On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
Oh, really? Where are the numbers you have to support this, may I
say, unlikely claim?
It seemed to me t
On Wed, 2006-03-01 at 08:24 -0500, Richard Kenner wrote:
> So this is likely to be a FE Ada coding bug and not a FE/ME/BE interface
> issue, thanks for spotting this!
>
> Sorry, my last suggestion is clearly wrong. I think is right.
>
> *** uintp.adb 12 Sep 2003 21:50:56 - 1.80
On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > 4.1 performs very poorly on IA32/x86-64, comparing against gcc 4.2.
>
> Oh, really? Where are the numb
On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > It is the issue of quality of gcc 4.1 on IA32/x86-64. The current gcc
> > > 4.1 performs very poorly on IA32/x86-64, comparin
On Wed, Mar 01, 2006 at 10:43:40PM +0100, Richard Guenther wrote:
> On 3/1/06, H. J. Lu <[EMAIL PROTECTED]> wrote:
> > On Wed, Mar 01, 2006 at 10:06:57PM +0100, Steven Bosscher wrote:
> > > On Wednesday 01 March 2006 21:49, H. J. Lu wrote:
> > > > It is the issue of quality of gcc 4.1 on IA32/x86-6
> That is the whole point: I'd like to back port the -mtune=generic
> change to 4.1 branch. There are so many different IA32/x86-64
> processors. The default optimization is more useful than -mtune=xxx.
> The new default (-mtune=generic) is much better than the old one for
> the current IA32/x86-64
H. J. Lu wrote:
> Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> using "-O2 -ffast-math" on Nocona:
Steven's right; this is clearly a new feature. HJ's also right; we've
made exceptions before.
Like Steven, I would like to see what the difference is between
-mtune=generic
Joe Buck wrote:
> What is the basis for the report that older tars don't work?
This posting:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
It may certainly be the case that some patched version of tar on RHEL
works fine (one would indeed hope and expect that distributors are
adding va
Here's the next segment in the ongoing saga of VRP vs Ada...
Not surprisingly we have another case where an object gets a
value outside of its TYPE_MIN_VALUE/TYPE_MAX_VALUE defined range.
Investigating the c460008 testsuite failure we have the following
code for Fixed_To_Short before VRP runs:
On Wed, Mar 01, 2006 at 02:24:58PM -0800, Mark Mitchell wrote:
> Joe Buck wrote:
>
> > What is the basis for the report that older tars don't work?
>
> This posting:
>
> http://gcc.gnu.org/ml/gcc-patches/2006-02/msg01861.html
>
> It may certainly be the case that some patched version of tar on
On Wednesday 01 March 2006 22:06, Steven Bosscher wrote:
> Your patch implements a new feature. New features usually don't fix
> regression. So your patch should be considered for GCC 4.1 IMHO.
I mean should not, obviously.
Gr.
Steven
On Wed, Mar 01, 2006 at 02:19:47PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of SPEC CPU 2K between before and after with gcc 4.1
> > using "-O2 -ffast-math" on Nocona:
>
> Steven's right; this is clearly a new feature. HJ's also right; we've
> made exceptions before.
>
On Wednesday 01 March 2006 23:51, H. J. Lu wrote:
> I'd like to see the default -O2 generate decent code for Nocona.
But then, you did so too months ago, when the GCC 4.1 development
cycle was still in stage1/stage2. Nocona has been around for a
very long time already (I have a Prescott-T myself
H. J. Lu wrote:
> Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> "-O2 -mtune=generic -ffast-math" on Nocona:
A 1.5% performance improvement, while certainly significant for some
users, is not worth taking any serious risks on a release branch. The
purpose of bug-fix releases on the relea
Ok this test is checking a corner case of the language, namely
non power of two modular types.
It looks like this one needs overflow checking to pass (-gnato):
$ gnatmake -f -I../../../support/ c460008.adb
gcc -c -I../../../support/ c460008.adb
gcc -c -I./ -I../../../support/ -I-
/home/guerby/wo
It looks like this one needs overflow checking to pass (-gnato):
ACATS should aways be run with -gnato since that's the only way to
get the behavior mandated by RM. Why are we running it without it? Is
this new? Certainly -gnato was used during validations.
Richard, Arnaud, could you c
On Wed, 2006-03-01 at 18:48 -0500, Richard Kenner wrote:
> It looks like this one needs overflow checking to pass (-gnato):
>
> ACATS should aways be run with -gnato since that's the only way to
> get the behavior mandated by RM. Why are we running it without it? Is
> this new? Certainly -g
Laurent GUERBY wrote:
Ok this test is checking a corner case of the language, namely
non power of two modular types.
It looks like this one needs overflow checking to pass (-gnato):
All ACATS tests should be run with -gnatE -gnato
On Mar 1, 2006, at 3:47 AM, HASSAN AL MOATASSIME wrote:
I have a problem with the compiler gcc 3.4.4.
With the gcc 3.2 compiler, i have no problem with the following
instruction :
creal(U0[i])=PartieReelle;
cimag(U0[i])=PartieImaginaire;
Now with the gcc 3.4.4 i
On GCC we use -gnato on tests known to need it
(/gcc/testsuite/ada/acats/overflow.lst) since we want to test flags
the typical GCC/Ada user does use and not what official validation
requires (which is -gnato -gnatE IIRC).
Well that would make the most sense if the code in the ACATS
On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> H. J. Lu wrote:
>
> > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > "-O2 -mtune=generic -ffast-math" on Nocona:
>
> A 1.5% performance improvement, while certainly significant for some
> users, is not worth taking any ser
On Wed, Mar 01, 2006 at 04:05:16PM -0800, H. J. Lu wrote:
> On Wed, Mar 01, 2006 at 03:06:46PM -0800, Mark Mitchell wrote:
> > H. J. Lu wrote:
> >
> > > Here are diffs of "-O2 -mtune=nocona -ffast-math" vs
> > > "-O2 -mtune=generic -ffast-math" on Nocona:
> >
> > A 1.5% performance improvement, w
--- Daniel Jacobowitz <[EMAIL PROTECTED]> wrote:
> On Wed, Mar 01, 2006 at 06:20:53PM +, Steven Newbury wrote:
> > OK, thank-you. I'll target "arm-iwmmxt-linux-gnueabi" with --with-cpu= etc
> and
> > --disable-multilib. The vendor string is for my build scripts and also
> will
> > help diff
> Richard, Arnaud, could you check amongst GNAT experts if for such types
> (non power of two modulus), it's not worth enabling overflow checks by
> default now that we have VRP doing non trivial optimisations? People
> using non power of two modulus are not caring for performance anyway, so
> havi
Laurent GUERBY wrote:
VRP might now force us to update the overflow list but I'm not sure
about switching to a full -gnato everywhere.
well you can expect some fiddling each version if you work this way
Eric Botcazou wrote:
Richard, Arnaud, could you check amongst GNAT experts if for such types
(non power of two modulus), it's not worth enabling overflow checks by
default now that we have VRP doing non trivial optimisations? People
using non power of two modulus are not caring for performance an
H. J. Lu wrote:
> You are comparing apply with orange. If a user uses -O2, he/she will
> see much more than that.
We can argue about that, but I don't think so. I'm comparing a user can
achieve without the patch with the performance they can achieve with the
patch. On all chips, for all time, u
On Thu, Mar 02, 2006 at 12:27:46AM +, Steven Newbury wrote:
> I've given this a go. I've successully built a stage1 cross compiler and
> installed the glibc headers. However, on re-building gcc it fails to link
> libgcc:
>
> ... ./libgcc_s.so.1.backup; else true; fi && mv ./libgcc_s.so.1.tmp
Daniel Towner <[EMAIL PROTECTED]> writes:
> I maintain a port of gcc for an embedded processor which has a HALT
> instruction. This instruction stops the processor, and generates an
> appropriate interrupt to indicate to its parent system that it has
> stopped. The instruction is accessed by the p
On 03/01/06 17:51, H. J. Lu wrote:
> SPECint_base2000 1.31%
> SPECfp_base2000 1.62%
>
All these numbers are within the usual SPEC noise. Not Worth It.
Greg Schafer wrote:
> Remove the -j3 and all is well. I suppose most folks never run `make
> install' in parallel.. but sometimes it's convenient to just simply:
>
> export MAKEFLAGS=-j3
>
> for big compile jobs.
I'm not aware of anything parallel-make unfriendly about my patch, but I
can beli
> Dan Kegel writes:
>> The problem has nothing to do with warnings from tar, which are neither
>> errors nor silent failures. I believe a file either got skipped or
>> unpacked with the wrong name.
Dan> Egads. Can you point me to more info? I've been building with older
Dan> versions of t
David Edelsohn <[EMAIL PROTECTED]> writes:
> Upgrading GNU tar to 1.15.1 fixed the problem for me.
So what is the actual requirement - 1.14 or "1.14 or above" ?
--
With regards, Roman.
83 matches
Mail list logo
