|
From: Bart V. A. <bar...@gm...> - 2009-02-22 12:44:47
|
Hello Nicholas, Apparently commit r9202 broke the PPC build. Can you please have a look at this ? I get the following output for the trunk when building on a ppc64 system (r9201 builds fine on the same system): $ svn co -r9202 svn://svn.valgrind.org/valgrind/trunk valgrind-r9202 && cd valgrind-r9202 && ./autogen.sh && ./configure && make -s check ... Making check in ppc32 /usr/bin/ld: skipping incompatible /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.so when searching for -lc /usr/bin/ld: skipping incompatible /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.a when searching for -lc /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o' is incompatible with powerpc:common64 output /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o' is incompatible with powerpc:common64 output /usr/bin/ld: warning: powerpc:common architecture of input file `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crtn.o' is incompatible with powerpc:common64 output /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o: In function `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against `__libc_start_main' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function `call_gmon_start': (.text+0x1a): undefined reference to `_GLOBAL_OFFSET_TABLE_' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function `call_gmon_start': (.text+0x1e): undefined reference to `_GLOBAL_OFFSET_TABLE_' /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function `call_gmon_start': (.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against `__gmon_start__' /usr/bin/ld: bug129390-ppc32.o(.text+0x1c): unresolvable R_PPC64_REL24 relocation against symbol`puts@@GLIBC_2.3' /usr/bin/ld: bug129390-ppc32.o(.text+0xbc): unresolvable R_PPC64_REL24 relocation against symbol`puts@@GLIBC_2.3' /usr/bin/ld: final link failed: Nonrepresentable section on output collect2: ld returned 1 exit status make[5]: *** [bug129390-ppc32] Error 1 make[4]: *** [check-am] Error 2 make[3]: *** [check-recursive] Error 1 make[2]: *** [check-recursive] Error 1 make[1]: *** [check-recursive] Error 1 make: *** [check] Error 2 Bart. |
|
From: Julian S. <js...@ac...> - 2009-02-22 13:00:26
|
r9216 builds and installs fine on ppc970 running openSuSE 11.0. Perhaps it is the cross compile stuff that is now broken? J On Sunday 22 February 2009, Bart Van Assche wrote: > Hello Nicholas, > > Apparently commit r9202 broke the PPC build. Can you please have a > look at this ? > > I get the following output for the trunk when building on a ppc64 > system (r9201 builds fine on the same system): > > $ svn co -r9202 svn://svn.valgrind.org/valgrind/trunk valgrind-r9202 > && cd valgrind-r9202 && ./autogen.sh && ./configure && make -s check > ... > Making check in ppc32 > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.so when searching > for -lc > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.a when searching > for -lc > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o' is > incompatible with powerpc:common64 output > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o' is > incompatible with powerpc:common64 output > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crtn.o' is > incompatible with powerpc:common64 output > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o: In function > `_start': (.text+0x20): relocation truncated to fit: R_PPC_REL24 against > `__libc_start_main' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x1a): undefined reference to `_GLOBAL_OFFSET_TABLE_' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x1e): undefined reference to `_GLOBAL_OFFSET_TABLE_' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against > `__gmon_start__' > /usr/bin/ld: bug129390-ppc32.o(.text+0x1c): unresolvable R_PPC64_REL24 > relocation against symbol`puts@@GLIBC_2.3' > /usr/bin/ld: bug129390-ppc32.o(.text+0xbc): unresolvable R_PPC64_REL24 > relocation against symbol`puts@@GLIBC_2.3' > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: ld returned 1 exit status > make[5]: *** [bug129390-ppc32] Error 1 > make[4]: *** [check-am] Error 2 > make[3]: *** [check-recursive] Error 1 > make[2]: *** [check-recursive] Error 1 > make[1]: *** [check-recursive] Error 1 > make: *** [check] Error 2 > > > Bart. > > --------------------------------------------------------------------------- >--- Open Source Business Conference (OSBC), March 24-25, 2009, San > Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing > the Enterprise -Strategies to boost innovation and cut costs with open > source participation -Receive a $600 discount off the registration fee with > the source code: SFAD http://p.sf.net/sfu/XcvMzF8H > _______________________________________________ > Valgrind-developers mailing list > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-developers |
|
From: Bart V. A. <bar...@gm...> - 2009-02-22 13:16:56
|
On Sun, Feb 22, 2009 at 2:00 PM, Julian Seward <js...@ac...> wrote: > > r9216 builds and installs fine on ppc970 running openSuSE 11.0. > Perhaps it is the cross compile stuff that is now broken? The output I posted was the output of a native build. I saw the same behavior on Fedora 7 and on openSUSE 10.3, both running on PS/3 hardware. $ uname -a Linux cell11 2.6.22-5.20070920bsc #1 SMP Tue Sep 25 10:49:16 CEST 2007 ppc64 ppc64 ppc64 GNU/Linux Bart. |
|
From: Bart V. A. <bar...@gm...> - 2009-02-22 13:28:12
|
On Sun, Feb 22, 2009 at 1:44 PM, Bart Van Assche <bar...@gm...> wrote: > Hello Nicholas, > > Apparently commit r9202 broke the PPC build. Can you please have a > look at this ? > > I get the following output for the trunk when building on a ppc64 > system (r9201 builds fine on the same system): > > $ svn co -r9202 svn://svn.valgrind.org/valgrind/trunk valgrind-r9202 > && cd valgrind-r9202 && ./autogen.sh && ./configure && make -s check > ... > Making check in ppc32 > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.so when searching > for -lc > /usr/bin/ld: skipping incompatible > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.a when searching > for -lc > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o' is > incompatible with powerpc:common64 output > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o' is > incompatible with powerpc:common64 output > /usr/bin/ld: warning: powerpc:common architecture of input file > `/usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crtn.o' is > incompatible with powerpc:common64 output > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crt1.o: In function `_start': > (.text+0x20): relocation truncated to fit: R_PPC_REL24 against > `__libc_start_main' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x1a): undefined reference to `_GLOBAL_OFFSET_TABLE_' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x1e): undefined reference to `_GLOBAL_OFFSET_TABLE_' > /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../crti.o: In function > `call_gmon_start': > (.text+0x2c): relocation truncated to fit: R_PPC_PLTREL24 against > `__gmon_start__' > /usr/bin/ld: bug129390-ppc32.o(.text+0x1c): unresolvable R_PPC64_REL24 > relocation against symbol`puts@@GLIBC_2.3' > /usr/bin/ld: bug129390-ppc32.o(.text+0xbc): unresolvable R_PPC64_REL24 > relocation against symbol`puts@@GLIBC_2.3' > /usr/bin/ld: final link failed: Nonrepresentable section on output > collect2: ld returned 1 exit status > make[5]: *** [bug129390-ppc32] Error 1 > make[4]: *** [check-am] Error 2 > make[3]: *** [check-recursive] Error 1 > make[2]: *** [check-recursive] Error 1 > make[1]: *** [check-recursive] Error 1 > make: *** [check] Error 2 Sorry, but an important piece of information was missing in the above output, namely the actual compile command. Here it is: $ make -C none/tests/ppc32 check make: Entering directory `/net/home/bart/software/valgrind/nightly/valgrind/none/tests/ppc32' make bug129390-ppc32 bug139050-ppc32 ldstrev lsw jm-insns mftocrf mcrfs round test_fx test_gx testVMX twi tw xlc_dbl_u32 make[1]: Entering directory `/net/home/bart/software/valgrind/nightly/valgrind/none/tests/ppc32' gcc -Winline -Wall -Wshadow -g -m64 -m32 -Wno-long-long -Wno-pointer-sign -Wdeclaration-after-statement -fno-stack-protector -o bug129390-ppc32 bug129390-ppc32.o /usr/bin/ld: skipping incompatible /usr/lib/gcc/ppc64-redhat-linux/4.1.2/../../../libc.so when searching for -lc ... As you can see both the command-line options -m64 and -m32 have been passed to gcc for the linking step. That was probably unintentional ? Bart. |
|
From: Nicholas N. <n.n...@gm...> - 2009-02-22 23:40:17
|
On Mon, Feb 23, 2009 at 12:28 AM, Bart Van Assche <bar...@gm...> wrote: > > As you can see both the command-line options -m64 and -m32 have been > passed to gcc for the linking step. That was probably unintentional ? Interestingly, this didn't cause problems on x86/Linux and AMD64/Linux. It's now fixed on the trunk. Thanks for the report -- it's inevitable that I'll occasionally break PPC stuff with the Darwin-related changes I'm making, because I don't have access to a PPC machine to test on. So it's useful to get these reports, and the cellbuzz nightly tests. Julian, didn't you have a PPC nightly test going at one point? Nick |
|
From: Julian S. <js...@ac...> - 2009-02-22 23:53:17
|
> Julian, didn't you have a PPC nightly test going at one point? We're no longer running a ppc64 box 24x7 (unnecessary energy hog). I do have a ppc32 box (ppc mac mini) that runs 24x7, but Memcheck is unusable on it, because the ultra-optimised strlen in ld.so causes thousands of false errors, and unfortunately ld.so is stripped so it's not interceptable. It would be best to enhance Memcheck so as to be able to handle the cleverness in the optimised strlen, but chasing down the root causes in Memcheck is very difficult. J |