libtool error in building GCC
Hello, I am experiencing the following error when building TRUNK version of our port. I am not familar with libtool. In 4.4, GCC produces its own libtools under libstdc++v3 directory and other similar directories. But I cannot track how the libtool is generated. Even I remove libtool under libstdc++-v3 directory and rerun make and it cannot regenerate libtool again. Examining config.log, config.status and Makefile doesn't help me either. So I really get lost what is going wrong in 4.5 trunk. Any help is greatly appreciated. Thanks, Bingfeng Mei /bin/sh ../libtool --tag CXX --tag disable-shared --mode=compile /projects/firepath/tools/work/bmei/gcc-head/build/./gcc/xgcc -shared-libgcc -B/projects/firepath/tools/work/bmei/gcc-head/build/./gcc -nostdinc++ -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libstdc++-v3/src -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libstdc++-v3/src/.libs -nostdinc -B/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/newlib/ -isystem /projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/newlib/targ-include -isystem /projects/firepath/tools/work/bmei/gcc-head/src/newlib/libc/include -B/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libgloss/firepath -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libgloss/libnosys -L/projects/firepath/tools/work/bmei/gcc-head/src/libgloss/firepath -B/home/bmei/work/gcc-head/install/firepath-elf/bin/ -B/home/bmei/work/gcc-head/install/firepath-elf/lib/ -isystem /home/bmei/work/gcc-head/install/firepath-elf/include -isystem /home/bmei/work/gcc-head/install/firepath-elf/sys-include -I/projects/firepath/tools/work/bmei/gcc-head/src/libstdc++-v3/../gcc -I/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libstdc++-v3/include/firepath-elf -I/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libstdc++-v3/include -I/projects/firepath/tools/work/bmei/gcc-head/src/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -g -O2 -c -o array_type_info.lo ../../../../src/libstdc++-v3/libsupc++/array_type_info.cc /bin/sh: ../libtool: No such file or directory make[4]: *** [array_type_info.lo] Error 127 make[4]: Leaving directory `/projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf/libstdc++-v3/libsupc++ The following is my configuration command: CC="gcc -m32" CFLAGS="-g" ../src/configure --prefix=/home/bmei/work/gcc-head/install --enable-languages=c,c++ --disable-nls --target=firepath-elf --with-newlib --with-mpfr=/projects/firepath/tools/work/bmei/packages/mpfr/2.4.1 --with-gmp=/projects/firepath/tools/work/bmei/packages/gmp/4.3.0 --disable-libssp --with-headers --enable-checking --enable-multilib
Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat
On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote: > I've tracked down a failure in gdb to hit a breakpoint > set at printf to the the breakpoint being placed incorrectly. > > Here is the code generated for printf with -mhard-float: > > .loc 1 29 0 > .cfi_startproc > .LVL0: > mflr 0 > stwu 1,-112(1) > .LCFI0: > .cfi_def_cfa_offset 112 > stw 5,24(1) > stw 0,116(1) > stw 6,28(1) > stw 7,32(1) > stw 8,36(1) > stw 9,40(1) > stw 10,44(1) > bne- 1,.L2 <<< - 1 > .cfi_offset 65, 4 > .loc 1 29 0 <<< - 2 > stfd 1,48(1)<<< - 3 > stfd 2,56(1) > stfd 3,64(1) > stfd 4,72(1) > stfd 5,80(1) > stfd 6,88(1) > stfd 7,96(1) > stfd 8,104(1) > .L2: > .loc 1 34 0 > > Gdb places a breakpoint at printf() at the stfd instruction (3). > This appears to be because of the .loc at (2). When the code is > executed, the branch (1) is taken, jumping over the the breakpoint. > I think that the .loc at (2) should not be generated, since it is > in the middle of the prologue code. Luis, isn't there a bugzilla regarding this? This seems to me to be similar to what you had been looking at. Peter
RE: libtool error in building GCC
Just ignore my previous mail. I find the error is because we failed to import the new 4.5 directory libstdc++v3/python to our repository. > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On > Behalf Of Bingfeng Mei > Sent: 21 July 2009 12:41 > To: gcc@gcc.gnu.org > Subject: libtool error in building GCC > > Hello, > I am experiencing the following error when building TRUNK > version of our port. > I am not familar with libtool. In 4.4, GCC produces its own > libtools under > libstdc++v3 directory and other similar directories. But I > cannot track > how the libtool is generated. Even I remove libtool under > libstdc++-v3 directory > and rerun make and it cannot regenerate libtool again. > Examining config.log, > config.status and Makefile doesn't help me either. So I > really get lost what > is going wrong in 4.5 trunk. Any help is greatly appreciated. > > Thanks, > Bingfeng Mei > > > /bin/sh ../libtool --tag CXX --tag disable-shared > --mode=compile > /projects/firepath/tools/work/bmei/gcc-head/build/./gcc/xgcc > -shared-libgcc > -B/projects/firepath/tools/work/bmei/gcc-head/build/./gcc > -nostdinc++ > -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libstdc++-v3/src > -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libstdc++-v3/src/.libs -nostdinc > -B/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/newlib/ -isystem > /projects/firepath/tools/work/bmei/gcc-head/build/firepath-elf > /newlib/targ-include -isystem > /projects/firepath/tools/work/bmei/gcc-head/src/newlib/libc/in > clude > -B/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libgloss/firepath > -L/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libgloss/libnosys > -L/projects/firepath/tools/work/bmei/gcc-head/src/libgloss/fir > epath -B/home/bmei/work/gcc-head/install/firepath-elf/bin/ > -B/home/bmei/work/gcc-head/install/firepath-elf/lib/ -isystem > /home/bmei/work/gcc-head/install/firepath-elf/include > -isystem > /home/bmei/work/gcc-head/install/firepath-elf/sys-include > -I/projects/firepath/tools/work/bmei/gcc-head/src/libstdc++-v3 > /../gcc > -I/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libstdc++-v3/include/firepath-elf > -I/projects/firepath/tools/work/bmei/gcc-head/build/firepath-e > lf/libstdc++-v3/include > -I/projects/firepath/tools/work/bmei/gcc-head/src/libstdc++-v3 > /libsupc++ -fno-implicit-templates -Wall -Wextra > -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once > -ffunction-sections -fdata-sections -g -O2 -c -o > array_type_info.lo > ../../../../src/libstdc++-v3/libsupc++/array_type_info.cc > /bin/sh: ../libtool: No such file or directory > make[4]: *** [array_type_info.lo] Error 127 > make[4]: Leaving directory > `/projects/firepath/tools/work/bmei/gcc-head/build/firepath-el > f/libstdc++-v3/libsupc++ > > > The following is my configuration command: > > CC="gcc -m32" CFLAGS="-g" ../src/configure > --prefix=/home/bmei/work/gcc-head/install > --enable-languages=c,c++ --disable-nls --target=firepath-elf > --with-newlib > --with-mpfr=/projects/firepath/tools/work/bmei/packages/mpfr/2 > .4.1 > --with-gmp=/projects/firepath/tools/work/bmei/packages/gmp/4.3 > .0 --disable-libssp --with-headers --enable-checking > --enable-multilib > > >
Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat
Hi, Yes, this is exactly what i was chasing some time ago. The GCC fix i had in mind (it just changes the ordering of statements) didn't get through since it dealt with arch-independent code and there was fear that this would break architectures other than PPC (or have the potential to do so). The breakpoint is placed at the wrong place due to the branch instruction in the prologue. GDB just assumes that the second BB is real code (not prologue anymore) since GCC never provided any useful information on where exactly the prologue ends. Original thread is here: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01213.html A fix on GDB's side proved to be harder than in GCC's side (since we're already assuming things, it would just be another workaround). Luis On Tue, 2009-07-21 at 08:38 -0500, Peter Bergner wrote: > On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote: > > I've tracked down a failure in gdb to hit a breakpoint > > set at printf to the the breakpoint being placed incorrectly. > > > > Here is the code generated for printf with -mhard-float: > > > > .loc 1 29 0 > > .cfi_startproc > > .LVL0: > > mflr 0 > > stwu 1,-112(1) > > .LCFI0: > > .cfi_def_cfa_offset 112 > > stw 5,24(1) > > stw 0,116(1) > > stw 6,28(1) > > stw 7,32(1) > > stw 8,36(1) > > stw 9,40(1) > > stw 10,44(1) > > bne- 1,.L2 <<< - 1 > > .cfi_offset 65, 4 > > .loc 1 29 0 <<< - 2 > > stfd 1,48(1)<<< - 3 > > stfd 2,56(1) > > stfd 3,64(1) > > stfd 4,72(1) > > stfd 5,80(1) > > stfd 6,88(1) > > stfd 7,96(1) > > stfd 8,104(1) > > .L2: > > .loc 1 34 0 > > > > Gdb places a breakpoint at printf() at the stfd instruction (3). > > This appears to be because of the .loc at (2). When the code is > > executed, the branch (1) is taken, jumping over the the breakpoint. > > I think that the .loc at (2) should not be generated, since it is > > in the middle of the prologue code. > > Luis, isn't there a bugzilla regarding this? This seems to me to > be similar to what you had been looking at. > > Peter > > >
Re: Incorrect line info in printf for powerpc-eabisim -mhard-foat
Actually, thinking further, the fix is for a consequence of the incorrect placement of the breakpoint right after the branch. I remember hitting the problem described too, but i didn't pursue a fix for that (yet). Luis On Tue, 2009-07-21 at 10:50 -0300, Luis Machado wrote: > Hi, > > Yes, this is exactly what i was chasing some time ago. The GCC fix i had > in mind (it just changes the ordering of statements) didn't get through > since it dealt with arch-independent code and there was fear that this > would break architectures other than PPC (or have the potential to do > so). > > The breakpoint is placed at the wrong place due to the branch > instruction in the prologue. GDB just assumes that the second BB is real > code (not prologue anymore) since GCC never provided any useful > information on where exactly the prologue ends. > > Original thread is here: > http://gcc.gnu.org/ml/gcc-patches/2009-02/msg01213.html > > A fix on GDB's side proved to be harder than in GCC's side (since we're > already assuming things, it would just be another workaround). > > Luis > > On Tue, 2009-07-21 at 08:38 -0500, Peter Bergner wrote: > > On Thu, 2009-07-16 at 13:55 -0700, Michael Eager wrote: > > > I've tracked down a failure in gdb to hit a breakpoint > > > set at printf to the the breakpoint being placed incorrectly. > > > > > > Here is the code generated for printf with -mhard-float: > > > > > > .loc 1 29 0 > > > .cfi_startproc > > > .LVL0: > > > mflr 0 > > > stwu 1,-112(1) > > > .LCFI0: > > > .cfi_def_cfa_offset 112 > > > stw 5,24(1) > > > stw 0,116(1) > > > stw 6,28(1) > > > stw 7,32(1) > > > stw 8,36(1) > > > stw 9,40(1) > > > stw 10,44(1) > > > bne- 1,.L2 <<< - 1 > > > .cfi_offset 65, 4 > > > .loc 1 29 0 <<< - 2 > > > stfd 1,48(1)<<< - 3 > > > stfd 2,56(1) > > > stfd 3,64(1) > > > stfd 4,72(1) > > > stfd 5,80(1) > > > stfd 6,88(1) > > > stfd 7,96(1) > > > stfd 8,104(1) > > > .L2: > > > .loc 1 34 0 > > > > > > Gdb places a breakpoint at printf() at the stfd instruction (3). > > > This appears to be because of the .loc at (2). When the code is > > > executed, the branch (1) is taken, jumping over the the breakpoint. > > > I think that the .loc at (2) should not be generated, since it is > > > in the middle of the prologue code. > > > > Luis, isn't there a bugzilla regarding this? This seems to me to > > be similar to what you had been looking at. > > > > Peter > > > > > > >
New port IA64 VMS and updated Alpha/VMS
AdaCore has been maintaining the IVMS and AVMS ports for many years and would like to submit our patches. The patches consolidate the common parts of AVMS and IVMS into a new config/vms directory. Since IVMS is a new port I believe the rules allow it to be submitted all at once, but it does requires removing files from the AVMS directory for the consolidation, plus makes quite a few dwarf2 debug changes and a few libiberty changes. I would like some guidance on how best to do it. FYI the IVMS patch is 5000 lines, the AVMS patch is about 2500 lines. 1) submit the target independent bits and pieces first then the configure bits. 2) submit the configure bits first, which will probably break the VMS ports for a while until the other bits are incorporated. --Douglas Rupp
Re: New port IA64 VMS and updated Alpha/VMS
Douglas B Rupp writes: > 1) submit the target independent bits and pieces first then the > configure bits. This seems like the right approach to me. Ian
Incorporation of Objective-C 2.0 changes into GCC trunk
All, Hey guys I'm wondering if there's a timeline for incorporating the Objective-C 2.0 changes from Apple into the trunk of GCC. If not, I would like to know what the GNUstep project can do to help make this happen. Thanks very much. :) Sincerely, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home)
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
Gregory Casamento wrote: > All, > > Hey guys I'm wondering if there's a timeline for incorporating the > Objective-C 2.0 changes from Apple into the trunk of GCC. > > If not, I would like to know what the GNUstep project can do to help > make this happen. No. But you just have to take patches from Apple's GCC, polish them and send them. Do Apple's changes rely on the NeXT runtime? If not, the job would be easier. Paolo
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
As far as I'm aware apple has an assignment for changes to gcc, so it should be possible to pull them in. On Tuesday, July 21, 2009, wrote: > Op 21 jul. 2009 21:50 schreef Paolo Bonzini : >> Gregory Casamento wrote: >> >> > Hey guys I'm wondering if there's a timeline for incorporating the >> > Objective-C 2.0 changes from Apple into the trunk of GCC. >> > >> > If not, I would like to know what the GNUstep project can do to help >> > make this happen. >> >> No. But you just have to take patches from Apple's GCC, polish them and >> send them. >> >> Do Apple's changes rely on the NeXT runtime? If not, the job would be >> easier. > > Do Apple's changes have the FSF as copyright holder? If not, the job would > be impossible. > > Ciao! > Steven -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home)
Re: Incorporation of Objective-C 2.0 changes into GCC trunk
Gregory Casamento wrote: > As far as I'm aware apple has an assignment for changes to gcc, so it > should be possible to pull them in. You're not forced to assign changes that you do not want to assign. Paolo
The Linux binutils 2.19.51.0.13 is released
This is the beta release of binutils 2.19.51.0.13 for Linux, which is
based on binutils 2009 0721 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been applied and
in what order they have been applied.
Starting from the 2.18.50.0.4 release, the x86 assembler no longer
accepts
fnstsw %eax
fnstsw stores 16bit into %ax and the upper 16bit of %eax is unchanged.
Please use
fnstsw %ax
Starting from the 2.17.50.0.4 release, the default output section LMA
(load memory address) has changed for allocatable sections from being
equal to VMA (virtual memory address), to keeping the difference between
LMA and VMA the same as the previous output section in the same region.
For
.data.init_task : { *(.data.init_task) }
LMA of .data.init_task section is equal to its VMA with the old linker.
With the new linker, it depends on the previous output section. You
can use
.data.init_task : AT (ADDR(.data.init_task)) { *(.data.init_task) }
to ensure that LMA of .data.init_task section is always equal to its
VMA. The linker script in the older 2.6 x86-64 kernel depends on the
old behavior. You can add AT (ADDR(section)) to force LMA of
.data.init_task section equal to its VMA. It will work with both old
and new linkers. The x86-64 kernel linker script in kernel 2.6.13 and
above is OK.
The new x86_64 assembler no longer accepts
monitor %eax,%ecx,%edx
You should use
monitor %rax,%ecx,%edx
or
monitor
which works with both old and new x86_64 assemblers. They should
generate the same opcode.
The new i386/x86_64 assemblers no longer accept instructions for moving
between a segment register and a 32bit memory location, i.e.,
movl (%eax),%ds
movl %ds,(%eax)
To generate instructions for moving between a segment register and a
16bit memory location without the 16bit operand size prefix, 0x66,
mov (%eax),%ds
mov %ds,(%eax)
should be used. It will work with both new and old assemblers. The
assembler starting from 2.16.90.0.1 will also support
movw (%eax),%ds
movw %ds,(%eax)
without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are
available at
http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch
http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch
The ia64 assembler is now defaulted to tune for Itanium 2 processors.
To build a kernel for Itanium 1 processors, you will need to add
ifeq ($(CONFIG_ITANIUM),y)
CFLAGS += -Wa,-mtune=itanium1
AFLAGS += -Wa,-mtune=itanium1
endif
to arch/ia64/Makefile in your kernel source tree.
Please report any bugs related to binutils 2.19.51.0.13 to
hjl.to...@gmail.com
and
http://www.sourceware.org/bugzilla/
Changes from binutils 2.19.51.0.12:
1. Update from binutils 2009 0721.
2. Fix linker for undefined STT_GNU_IFUNC symbols. PR 10426.
3. Fix x86 assembler for nops in 64bit. PR 10420.
4. Add a new option, --insn-width, to objdump.
5. Improve arm support.
6. Improve mips support.
7. Improve gold support.
Changes from binutils 2.19.51.0.11:
1. Update from binutils 2009 0716.
2. Fix x86 assembler for jumping to local STT_GNU_IFUNC symbols.
3. Fix x86 linker for relocatable link with local STT_GNU_IFUNC symbols.
4. Implement ppc STT_GNU_IFUNC support.
5. Support x86 FMA4.
6. Fix linker regression with Linux kernel build.
7. Support unordered references in DWARF reader.
8. Improve arm support.
9. Improve m10300 support.
10. Improve ppc support.
11. Improve spu support.
12. Improve gold support.
Changes from binutils 2.19.51.0.10:
1. Update from binutils 2009 0627.
2. Fix strip on static executable with STT_GNU_IFUNC symbol. PR 10337.
3. Add STB_GNU_UNIQUE support.
4. Fix objcopy on empty file. PR 10321.
5. Fix debug section for PE-COFF.
6. Suport build with gcc 4.5.0.
7. Improve arm support.
8. Improve ppc support.
9. Improve m10300 support.
10. Improve mep support.
11. Improve MacOS support.
12. Improve gold support.
Changes from binutils 2.19.51.0.9:
1. Update from binutils 2009 0618.
2. Update STT_GNU_IFUNC symbol support. PR 10269/10270.
3. Fix an assembler CFI bug. PR 10255.
4. Improve objdump. PR 10263/10288
5. Improve readelf.
6. Improve arm support.
7. Improve moxie support.
8. Improve spu support.
9. Improve vax support.
10. Improve COFF/PE support.
11. Improve MacOS support.
Changes from binutils 2.19.51.0.8:
1. Update from binutils 2009 0606.
2. Update STT_GNU_IFUNC symbol support.
Changes from binutils 2.19.51.0.7:
1. Update from binutils 2009 0603.
2. Fix STT_GNU_IFUNC symbol with pointer equality.
Changes from binutils 2.19.51.0.6:
1. Update from binutils 2009 0601.
2. Update STT_GNU_IFUNC support. PR 10205.
3. Fix x86 asssembler Intel syntax regression with '$'. PR 10198.
Changes from binutils 2.19.51.0.5:
1. Update from binutils 2009 0529.
2. Rewrite STT_GNU_IFUN
gcc-4.4-20090721 is now available
Snapshot gcc-4.4-20090721 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090721/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.4 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch revision 149868 You'll find: gcc-4.4-20090721.tar.bz2 Complete GCC (includes all of below) gcc-core-4.4-20090721.tar.bz2 C front end and core compiler gcc-ada-4.4-20090721.tar.bz2 Ada front end and runtime gcc-fortran-4.4-20090721.tar.bz2 Fortran front end and runtime gcc-g++-4.4-20090721.tar.bz2 C++ front end and runtime gcc-java-4.4-20090721.tar.bz2 Java front end and runtime gcc-objc-4.4-20090721.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.4-20090721.tar.bz2The GCC testsuite Diffs from 4.4-20090714 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.4 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
[mep] legitimizing control registers
Committed. * config/mep/mep.c (mep_legitimize_arg): Leave control registers alone too. Index: config/mep/mep.c === --- config/mep/mep.c(revision 149868) +++ config/mep/mep.c(working copy) @@ -6201,13 +6201,15 @@ mep_legitimize_arg (const struct insn_op The caller will copy this value into ARG after the main instruction. By doing this always, we produce slightly more optimal code. */ /* But not for control registers. */ if (operand->constraint[0] == '=' && (! REG_P (arg) - || ! (CCR_REGNO_P (REGNO (arg)) || CR_REGNO_P (REGNO (arg))) + || ! (CONTROL_REGNO_P (REGNO (arg)) + || CCR_REGNO_P (REGNO (arg)) + || CR_REGNO_P (REGNO (arg))) )) return gen_reg_rtx (operand->mode); /* Try simple mode punning. */ arg = mep_convert_arg (operand->mode, arg); if (operand->predicate (arg, operand->mode))
