2013/6/22 Ian Lance Taylor :
> On Sat, Jun 22, 2013 at 12:17 AM, Chung-Ju Wu wrote:
>> Like this?
>>
>> ===
>> --- libgcc/Makefile.in (revision 200306)
>> +++ libgcc/Makefile.in (working copy)
>> @@ -121,8 +121,8 @@
>> .PHONY: all
On Sat, Jun 22, 2013 at 12:17 AM, Chung-Ju Wu wrote:
> Like this?
>
> ===
> --- libgcc/Makefile.in (revision 200306)
> +++ libgcc/Makefile.in (working copy)
> @@ -121,8 +121,8 @@
> .PHONY: all clean
>
> clean:
> - -rm -f aut
2013/6/22 Andreas Schwab :
> Chung-Ju Wu writes:
>
>> clean:
>> - -rm -f auto-target.h libgcc_tm.h libgcc.map
>> + -rm -f libgcc_tm.h libgcc.map
>> -rm -f libgcc_tm.stamp stamp-h stmp-ldirs
>
> Same for stamp-h.
>
Like this?
==
Chung-Ju Wu writes:
> clean:
> - -rm -f auto-target.h libgcc_tm.h libgcc.map
> + -rm -f libgcc_tm.h libgcc.map
> -rm -f libgcc_tm.stamp stamp-h stmp-ldirs
Same for stamp-h.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 0
2013/6/22 Ian Lance Taylor :
> On Thu, Jun 20, 2013 at 6:25 PM, Mike Stump wrote:
>> A make clean followed by a make in the libgcc directory results in:
>>
>> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error:
>> auto-target.h: No such file or directory
>> #include "auto-target.h"
On Thu, Jun 20, 2013 at 6:25 PM, Mike Stump wrote:
> A make clean followed by a make in the libgcc directory results in:
>
> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error:
> auto-target.h: No such file or directory
> #include "auto-target.h"
>
> Oh, the the old days, we'd just
Mike Stump writes:
> A make clean followed by a make in the libgcc directory results in:
>
> ../../../../gcc/libgcc/config/i386/cpuinfo.c:23:25: fatal error:
> auto-target.h: No such file or directory
> #include "auto-target.h"
>
> Oh, the the old days, we'd just add a dependancy… If someone kn
Hi Marc,
Please see my response below.
> -Original Message-
> From: Marc Glisse [mailto:marc.gli...@inria.fr]
> Sent: Tuesday, January 08, 2013 6:20 PM
> To: Iyer, Balaji V
> Cc: 'gcc@gcc.gnu.org'
> Subject: RE: Build error in genconstants.c
>
>
On Tue, 8 Jan 2013, Iyer, Balaji V wrote:
Thanks for your response. I looked at config.log and I got the
following information about sbrk. This error only occurs when I type
"make." If I reconfigured the build directory and typed "make -j8" (or
whatever the number of cores I have on my machin
std.h:1046:14: note: previous declaration of 'sbrk' was here
extern void *sbrk (intptr_t __delta) __THROW;
../../trunk-gcc/gcc/system.h:446:14: error: conflicting types for 'sbrk'
extern void *sbrk (int);
/usr/include/unistd.h:1046:14: note: previous declaration of 'sbrk&#x
On Tue, 8 Jan 2013, Iyer, Balaji V wrote:
Hello Everyone,
I am getting the following error when I tried to build the trunk (revision
194999) on my SuSE machine (Linux 2.6.32.29-0.3-default x86_64). I just did the
standard configure (../src_directory/configure --prefix=<>). It looks li
Jeff Kuskin writes:
> I'm trying to remove *all* single-letter constraints from my cpu.md
> file and replace them with define_constraint entries that define
> *multi-letter* constraint names. Example: (define_constraint "aFOO"
> ...)
> Am I *required* to define at least some of the single-lett
On 05/11/2010 02:00 PM, Diego Novillo wrote:
checking libelf.h usability... yes
checking libelf.h presence... yes
checking for libelf.h... yes
checking gelf.h usability... yes
checking gelf.h presence... yes
checking for gelf.h... yes
checking libelf/libelf.h usability... yes
checking libelf/li
On Tue, May 11, 2010 at 6:30 PM, Diego Novillo wrote:
> [ Moved to gcc@gcc.gnu.org ]
> Hmm, it did not detect elf_getshdrstrndx and yet it tried to use it
> later on. I think that's the bug. Yes, please file a bug. I believe
> it's going to be easy to fix, though. There should be an unguarded
>
[ Moved to gcc@gcc.gnu.org ]
On Tue, May 11, 2010 at 08:46, Sandeep Soni wrote:
> On Tue, May 11, 2010 at 4:53 PM, Diego Novillo wrote:
>> On Tue, May 11, 2010 at 02:24, Sandeep Soni wrote:
>>
>>> I installed elfutils-libelf-devel-0.145-1 and that worked.
>>
>> Yes. Older libelfs will not work
Janus Weil wrote:
Building trunk rev. 139857 on linux/x86_64, I get the following failure:
...
cc1: warnings being treated as errors
/home/local/jweil/gcc44/trunk/gcc/sel-sched-ir.c:946: error:
'cmp_v_in_regset_pool' defined but not used
I will commit the following as obvious once bootstrap fini
Building trunk rev. 139857 on linux/x86_64, I get the following failure:
...
cc1: warnings being treated as errors
/home/local/jweil/gcc44/trunk/gcc/sel-sched-ir.c:946: error:
'cmp_v_in_regset_pool' defined but not used
...
Cheers,
Janus
2008/9/1 M R Swami Reddy <[EMAIL PROTECTED]>:
> Hello,
>
Daniel Franke wrote:
SVN revision: 118109
Try 118110
Andreas
Brian Dessent <[EMAIL PROTECTED]> wrote:
>
> Consider posting this kind of question to gcc-help@ instead.
OK, I will.
> [EMAIL PROTECTED] wrote:
>
> > I just ran these commands:
> >
> > svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
> > mkdir builddir
> > cd builddir
> > CFLAGS="-
Consider posting this kind of question to gcc-help@ instead.
[EMAIL PROTECTED] wrote:
> I just ran these commands:
>
> svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
> mkdir builddir
> cd builddir
> CFLAGS="-g" ../gcc/configure --enable-languages=c,c++ --enable-checking \
> --disable-boot
Andrew (and everybody else),
I upgraded autoconf because the build crashed when I tried to regenerate
the fortran library. There were already symbols present that were not
recognised by my autoconf (I kept no record of which - it was the
default with FC3). I upgraded to the version recommen
Andrew Pinski wrote:
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No wonder
On Tue, 2006-03-14 08:56:38 -0500, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
> >Among other differences, it decides that we're cross-building, which
> >isn't true in this case. This results in vax-linux-uclibc-gcc being
> >used to build libiber
On Mar 14, 2006, at 8:54 AM, Jan-Benedict Glaw wrote:
Among other differences, it decides that we're cross-building, which
isn't true in this case. This results in vax-linux-uclibc-gcc being
used to build libiberty for the build system (which is
i686-linux-gnu). No wonder that `genmode' cannot
24 matches
Mail list logo
