|
From: AA <nit...@ya...> - 2009-04-14 22:35:35
|
hi -- i've just followed the instructions from the valgrind webpage to get the source from SVN, and it's failing with the first thing it tries to compile during "make" with the error pasted below. I followed exactly the instructions on the website, with my only modification --prefix=/ul/amosa
The only thing suspicious in the preceding steps was this summary from the ./configure stage:
Maximum build arch: amd64
Primary build arch: amd64
Build OS: linux
Primary build target: AMD64_LINUX
Secondary build target: X86_LINUX
Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.3.supp
which is odd, because my system is not AMD, it's an Intel Dual-Core Xeon Processor 5100 (Woodcrest), 65nm, running CentOS 4.5 / RHEL 4... But I can't figure out how it drew this conclusion, or how to set it straight, assuming this is a problem.
Can somebody help me figure out what I'm doing wrong? Should I step back from the SVN and use the 3.4.1 bz2 install instead? The valgrind website doesn't have much to help figure out compile problems.
thanks!
Amos.
The error:
[hive]~/src/valgrind make
gcc -m32 -Wl,--verbose -nostdlib 2>&1 | sed \
-e '1,/^=====\+$/d' \
-e '/^=====\+$/,/.\*/d' \
-e '/\. = \(0x[0-9A-Fa-f]\+\|SEGMENT_START("[^"]\+", 0x[0-9A-Fa-f]\+)\) + SIZEOF_HEADERS/s/0x[0-9A-Fa-f]\+/valt_load_address/g' > valt_load_address_x86_linux.lds \
|| rm -f valt_load_address_x86_linux.lds
gcc -m64 -Wl,--verbose -nostdlib 2>&1 | sed \
-e '1,/^=====\+$/d' \
-e '/^=====\+$/,/.\*/d' \
-e '/\. = \(0x[0-9A-Fa-f]\+\|SEGMENT_START("[^"]\+", 0x[0-9A-Fa-f]\+)\) + SIZEOF_HEADERS/s/0x[0-9A-Fa-f]\+/valt_load_address/g' > valt_load_address_amd64_linux.lds \
|| rm -f valt_load_address_amd64_linux.lds
make all-recursive
Making all in include
Making all in vki
make[3]: Nothing to be done for `all'.
make[3]: Nothing to be done for `all-am'.
Making all in coregrind
make all-am
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -I../coregrind -DVG_LIBDIR="\"/ul/amosa/lib/valgrind"\" -DVG_PLATFORM="\"x86-linux\"" -m32 -O2 -g -Wmissing-prototypes -Wall -Wshadow -Wpointer-arith -Wstrict-prototypes -Wmissing-declarations -Wno-format-zero-length -fno-strict-aliasing -Wno-long-long -Wdeclaration-after-statement -MT libcoregrind_x86_linux_a-m_commandline.o -MD -MP -MF ".deps/libcoregrind_x86_linux_a-m_commandline.Tpo" -c -o libcoregrind_x86_linux_a-m_commandline.o `test -f 'm_commandline.c' || echo './'`m_commandline.c; \
then mv -f ".deps/libcoregrind_x86_linux_a-m_commandline.Tpo" ".deps/libcoregrind_x86_linux_a-m_commandline.Po"; else rm -f ".deps/libcoregrind_x86_linux_a-m_commandline.Tpo"; exit 1; fi
gcc -m32 -g -Wno-long-long -c -o libcoregrind_x86_linux_a-m_cpuid.o `test -f 'm_cpuid.S' || echo './'`m_cpuid.S
In file included from m_cpuid.S:31:
pub_core_basics_asm.h:42:33: pub_tool_basics_asm.h: No such file or directory
pub_core_basics_asm.h:45:20: config.h: No such file or directory
make[3]: *** [libcoregrind_x86_linux_a-m_cpuid.o] Error 1
make[2]: *** [all] Error 2
make[1]: *** [all-recursive] Error 1
make: *** [all] Error 2
|
|
From: Nicholas N. <n.n...@gm...> - 2009-04-14 23:29:44
|
On Wed, Apr 15, 2009 at 8:35 AM, AA <nit...@ya...> wrote: > > hi -- i've just followed the instructions from the valgrind webpage to get the source from SVN, and it's failing with the first thing it tries to compile during "make" with the error pasted below. I followed exactly the instructions on the website, with my only modification --prefix=/ul/amosa > > The only thing suspicious in the preceding steps was this summary from the ./configure stage: > Maximum build arch: amd64 > Primary build arch: amd64 > Build OS: linux > Primary build target: AMD64_LINUX > Secondary build target: X86_LINUX > Default supp files: exp-ptrcheck.supp xfree-3.supp xfree-4.supp glibc-2.X-drd.supp glibc-2.34567-NPTL-helgrind.supp glibc-2.3.supp > > which is odd, because my system is not AMD, it's an Intel Dual-Core Xeon Processor 5100 (Woodcrest), 65nm, running CentOS 4.5 / RHEL 4... But I can't figure out how it drew this conclusion, or how to set it straight, assuming this is a problem. "AMD64" is just another name for the architecture also known as "x86-64", it doesn't indicate what company made your chip. > In file included from m_cpuid.S:31: > pub_core_basics_asm.h:42:33: pub_tool_basics_asm.h: No such file or directory > pub_core_basics_asm.h:45:20: config.h: No such file or directory > make[3]: *** [libcoregrind_x86_linux_a-m_cpuid.o] Error 1 > make[2]: *** [all] Error 2 > make[1]: *** [all-recursive] Error 1 > make: *** [all] Error 2 I've seen this before, I think it's due to an old version of automake or autoconf. What versions of those are you running? Nick |
|
From: AA <nit...@ya...> - 2009-04-15 01:50:08
|
automake --version automake (GNU automake) 1.9.2 Written by Tom Tromey <tr...@re...>. Copyright 2004 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. If these are too old, then I'll have to nag my sysadmin to update them... But the valgrind website says here: http://valgrind.org/downloads/repository.html that I only need versions 1.7... Amos. --- On Tue, 4/14/09, Nicholas Nethercote <n.n...@gm...> wrote: > From: Nicholas Nethercote <n.n...@gm...> > Subject: Re: [Valgrind-users] can't compile valgrind, fails in make > To: nit...@ya... > Cc: val...@li... > Date: Tuesday, April 14, 2009, 4:29 PM > On Wed, Apr 15, 2009 at 8:35 AM, AA > <nit...@ya...> wrote: > > > > hi -- i've just followed the instructions from the > valgrind webpage to get the source from SVN, and it's > failing with the first thing it tries to compile during > "make" with the error pasted below. I followed > exactly the instructions on the website, with my only > modification --prefix=/ul/amosa > > > > The only thing suspicious in the preceding steps was > this summary from the ./configure stage: > > Maximum build arch: amd64 > > Primary build arch: amd64 > > Build OS: linux > > Primary build target: AMD64_LINUX > > Secondary build target: X86_LINUX > > Default supp files: exp-ptrcheck.supp > xfree-3.supp xfree-4.supp glibc-2.X-drd.supp > glibc-2.34567-NPTL-helgrind.supp glibc-2.3.supp > > > > which is odd, because my system is not AMD, it's > an Intel Dual-Core Xeon Processor 5100 (Woodcrest), 65nm, > running CentOS 4.5 / RHEL 4... But I can't figure out > how it drew this conclusion, or how to set it straight, > assuming this is a problem. > > "AMD64" is just another name for the architecture > also known as > "x86-64", it doesn't indicate what company > made your chip. > > > In file included from m_cpuid.S:31: > > pub_core_basics_asm.h:42:33: pub_tool_basics_asm.h: No > such file or directory > > pub_core_basics_asm.h:45:20: config.h: No such file or > directory > > make[3]: *** [libcoregrind_x86_linux_a-m_cpuid.o] > Error 1 > > make[2]: *** [all] Error 2 > > make[1]: *** [all-recursive] Error 1 > > make: *** [all] Error 2 > > I've seen this before, I think it's due to an old > version of automake > or autoconf. What versions of those are you running? > > Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-15 01:50:27
|
On Wed, Apr 15, 2009 at 11:43 AM, AA <nit...@ya...> wrote: > > automake --version > automake (GNU automake) 1.9.2 > Written by Tom Tromey <tr...@re...>. > > Copyright 2004 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > autoconf (GNU Autoconf) 2.59 > Written by David J. MacKenzie and Akim Demaille. > > Copyright (C) 2003 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I think it's automake that's the problem. > If these are too old, then I'll have to nag my sysadmin to update them... But the valgrind website says here: > http://valgrind.org/downloads/repository.html > that I only need versions 1.7... The build system has been updated recently, and those docs are out-of-date. It's not that we've started using some new automake features, it just seems that old versions are doing the wrong thing. Nick |
|
From: Florian K. <br...@ac...> - 2009-04-15 02:39:59
|
On Tuesday 14 April 2009 9:50:22 pm Nicholas Nethercote wrote: > On Wed, Apr 15, 2009 at 11:43 AM, AA <nit...@ya...> wrote: > > > > automake --version > > automake (GNU automake) 1.9.2 > > Written by Tom Tromey <tr...@re...>. > > > > Copyright 2004 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > > > > > > > autoconf (GNU Autoconf) 2.59 > > Written by David J. MacKenzie and Akim Demaille. > > > > Copyright (C) 2003 Free Software Foundation, Inc. > > This is free software; see the source for copying conditions. There is NO > > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > I think it's automake that's the problem. > This problem has come up in the past. It might be nice to document a working combination of autotools on the webpage. For example: autoconf (GNU Autoconf) 2.61 automake (GNU automake) 1.10.1 works. Florian |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-15 02:10:35
|
On Wed, Apr 15, 2009 at 11:50 AM, Nicholas Nethercote <n.n...@gm...> wrote: > > The build system has been updated recently, and those docs are > out-of-date. It's not that we've started using some new automake > features, it just seems that old versions are doing the wrong thing. automake 1.10 on my Mac has this documentation: 8.12 Assembly Support ===================== Automake includes some support for assembly code. There are two forms of assembler files: normal (`*.s') and preprocessed by `CPP' (`*.S'). The variable `CCAS' holds the name of the compiler used to build assembly code. This compiler must work a bit like a C compiler; in particular it must accept `-c' and `-o'. The values of `CCASFLAGS' and `AM_CCASFLAGS' (or its per-target definition) is passed to the compilation. For preprocessed files, `DEFS', `DEFAULT_INCLUDES', `INCLUDES', `CPPFLAGS' and `AM_CPPFLAGS' are also used. The autoconf macro `AM_PROG_AS' will define `CCAS' and `CCASFLAGS' for you (unless they are already set, it simply sets `CCAS' to the C compiler and `CCASFLAGS' to the C compiler flags), but you are free to define these variables by other means. Only the suffixes `.s' and `.S' are recognized by `automake' as being files containing assembly code. automake 1.8.5 on a Linux box has this: Assembly Support ================ Automake includes some support for assembly code. The variable `CCAS' holds the name of the compiler used to build assembly code. This compiler must work a bit like a C compiler; in particular it must accept `-c' and `-o'. The value of `CCASFLAGS' is passed to the compilation. You are required to set `CCAS' and `CCASFLAGS' via `configure.ac'. The autoconf macro `AM_PROG_AS' will do this for you. Unless they are already set, it simply sets `CCAS' to the C compiler and `CCASFLAGS' to the C compiler flags. Only the suffixes `.s' and `.S' are recognized by `automake' as being files containing assembly code. The problem is that m_cpuid.S (and some other .S files) needs the CPPFLAGS. With the old automake it's not getting them. So there are two possible paths: - increase the required version of automake. I'm not sure which version the changed behaviour was introduced. - copy CPPFLAGS into CCASFLAGS The latter is probably easier... Nick |
|
From: Nicholas N. <n.n...@gm...> - 2009-04-15 04:29:48
Attachments:
diff
|
On Wed, Apr 15, 2009 at 12:10 PM, Nicholas Nethercote <n.n...@gm...> wrote: > The problem is that m_cpuid.S (and some other .S files) needs the > CPPFLAGS. With the old automake it's not getting them. > > So there are two possible paths: > - increase the required version of automake. I'm not sure which > version the changed behaviour was introduced. > - copy CPPFLAGS into CCASFLAGS > > The latter is probably easier... Attached is a patch that does the latter. Amos, can you try it? You'll need to rerun all the install steps, including autogen.sh. Thanks. Nick |
|
From: AA <nit...@ya...> - 2009-04-15 06:43:09
|
it works! thanks!
amos.
--- On Tue, 4/14/09, Nicholas Nethercote <n.n...@gm...> wrote:
> From: Nicholas Nethercote <n.n...@gm...>
> Subject: Re: [Valgrind-users] can't compile valgrind, fails in make
> To: nit...@ya...
> Cc: val...@li...
> Date: Tuesday, April 14, 2009, 9:29 PM
> On Wed, Apr 15, 2009 at 12:10 PM, Nicholas Nethercote
> <n.n...@gm...> wrote:
> > The problem is that m_cpuid.S (and some other .S
> files) needs the
> > CPPFLAGS. With the old automake it's not getting
> them.
> >
> > So there are two possible paths:
> > - increase the required version of automake. I'm
> not sure which
> > version the changed behaviour was introduced.
> > - copy CPPFLAGS into CCASFLAGS
> >
> > The latter is probably easier...
>
> Attached is a patch that does the latter. Amos, can you
> try it?
> You'll need to rerun all the install steps, including
> autogen.sh.
> Thanks.
>
> Nick
|
|
From: Nicholas N. <n.n...@gm...> - 2009-04-16 00:32:37
|
On Wed, Apr 15, 2009 at 4:43 PM, AA <nit...@ya...> wrote: > > it works! thanks! I've committed the change on the trunk and DARWIN branch. Thanks for reporting it and testing the fix. Nick |