Summary: | dev-util/valgrind fails to compile due to -m64 in CFLAGS and CCASFLAGS | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Thomas Sachau <tommy> |
Component: | New packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | binki, vcgomes |
Priority: | Normal | ||
Version: | autobuilds | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
new build.log for 3.7.0-r3 |
Description
Thomas Sachau
2012-01-13 23:40:02 UTC
Created attachment 298899 [details]
build.log
Tommy, sorry for taking a while to come back to this, but I was investigating the related question of what the -mx32 flag does. This lead me down a long path of what the x32 abi looks like. Long story short, it leads to breakage. Anyhow, back to just -m64. I'm having trouble reproducing this despite the addition of CFLAGS_amd64="-m64" to arch/amd64/make.defaults. First let's make sure we're on the same page. I tested on two profiles: 1) hardened/linux/amd64 2) default/linux/amd64/10.0 In both cases =dev-util/valgrind-3.7.0-r2 emerged fine. Here are the differences between these and what you did: 1) You used a deprecated profile hardened/linux/amd64/10.0 2) I used portage-2.1.10.44, you used 2.2.0_alpha84-r1 3) I used glibc-2.13-r4, you used glibc-2.14.1-r2 There are other differences, but they are unconsequential. I know that if -m64 makes it in there we have problems, see bug #398447, but that is a different issue. Tommy anything more to shed light on this? (In reply to comment #2) > > I know that if -m64 makes it in there we have problems, see bug #398447, but > that is a different issue. > Sorry, I meant bug #398463 (In reply to comment #2) > 2) I used portage-2.1.10.44, you used 2.2.0_alpha84-r1 This is the main difference, since 2.2.0_alpha84-r1 is not simply portage-2.2, but multilib-portage, which does add CFLAGS_$target_abi to $CFLAGS and some other vars, which in this case does mean -m64. Unless you want to use/test multilib-portage yourself (ebuild is in the multilib-portage overlay), the easiest way to reproduce those issues for you is to add (on amd64) -m64 to CFLAGS, CXXFLAGS and LDFLAGS (In reply to comment #4) > (In reply to comment #2) > > 2) I used portage-2.1.10.44, you used 2.2.0_alpha84-r1 > > This is the main difference, since 2.2.0_alpha84-r1 is not simply portage-2.2, > but multilib-portage, which does add CFLAGS_$target_abi to $CFLAGS and some > other vars, which in this case does mean -m64. > > Unless you want to use/test multilib-portage yourself (ebuild is in the > multilib-portage overlay), the easiest way to reproduce those issues for you is > to add (on amd64) -m64 to CFLAGS, CXXFLAGS and LDFLAGS Okay now I understand how those flags make it into the build. Both -m64 and -mx32 are a problem so I filter-flag-ed them. Note: I rev bumped to -r3 rather than just adding to -r2 because ppc64 is thinking of stabilizing -r2, see bug #403355. In case these filters cause problems, its better to separate them out for more testing. Closing resolved. Reopen if there's still a problem with valgrind-3.7.0-r3. Created attachment 302431 [details]
new build.log for 3.7.0-r3
Seems like something still adds -m64, since the build still fails.
(In reply to comment #6) > Created attachment 302431 [details] > new build.log for 3.7.0-r3 > > Seems like something still adds -m64, since the build still fails. filter-flags does not work with the multilib portage as it does with mainline: 1) On a vanilla amd64 gentoo, I added -m64 to my CFLAGS in /etc/make.conf. Then valgrind-3.7.0-r2 fails while valgrind-3.7.0-r3 works. The difference between the two is 'filter-flags -m64 -mx32' in src_configure(). 2) On a multilib system (I used experimental/amd64/qemu/multilib-amd64-qemu-2012-01-04.tar.lzma), both valgrind-3.7.0-r2 and valgrind-3.7.0-r3 fail. The failing compiling line is: x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I.. -I.. -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVGPV_x86_linux_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/lib64/valgrind"\" -DVG_PLATFORM="\"x86-linux\"" -I.. -I../include -I../VEX/pub -DVGA_x86=1 -DVGO_linux=1 -DVGP_x86_linux=1 -DVGPV_x86_linux_vanilla=1 -I../coregrind -DVG_LIBDIR="\"/usr/lib64/valgrind"\" -DVG_PLATFORM="\"x86-linux\"" -m32 -g -O2 -march=nocona -pipe -m64 -c -o libcoregrind_x86_linux_a-m_cpuid.o `test -f 'm_cpuid.S' || echo './'`m_cpuid.S Note the last flag -m64 is appended after filter-flags. This brings up an important question in the whole multilib approach: do we want the user or build system to override the abi flag?
> Note the last flag -m64 is appended after filter-flags.
>
>
> This brings up an important question in the whole multilib approach: do we want
> the user or build system to override the abi flag?
binki noticed that the -m64 is added to the CCASFLAGS. A quick peek at flag-o-matic.eclass shows that these flags are not filtered. I added CCASFLAGS to the flags that fitler-flags does filter and that fixed the problem.
The fix is a trivial patch, but it should be passed by the gentoo-dev@ email list. I'll do that after a chance to comment on the bug.
Here's the patch:
--- flag-o-matic.eclass.orig 2012-01-16 21:03:32.000000000 +0100
+++ flag-o-matic.eclass 2012-02-19 11:24:12.000000000 +0100
@@ -17,7 +17,7 @@
# Return all the flag variables that our high level funcs operate on.
all-flag-vars() {
- echo {C,CPP,CXX,F,FC,LD}FLAGS
+ echo {C,CPP,CXX,CCAS,F,FC,LD}FLAGS
}
# {C,CXX,F,FC}FLAGS that we allow in strip-flags
(In reply to comment #8) > > Note the last flag -m64 is appended after filter-flags. > > > > > > This brings up an important question in the whole multilib approach: do we want > > the user or build system to override the abi flag? > > binki noticed that the -m64 is added to the CCASFLAGS. A quick peek at > flag-o-matic.eclass shows that these flags are not filtered. I added CCASFLAGS > to the flags that fitler-flags does filter and that fixed the problem. > > The fix is a trivial patch, but it should be passed by the gentoo-dev@ email > list. I'll do that after a chance to comment on the bug. > > Here's the patch: > > --- flag-o-matic.eclass.orig 2012-01-16 21:03:32.000000000 +0100 > +++ flag-o-matic.eclass 2012-02-19 11:24:12.000000000 +0100 > @@ -17,7 +17,7 @@ > > # Return all the flag variables that our high level funcs operate on. > all-flag-vars() { > - echo {C,CPP,CXX,F,FC,LD}FLAGS > + echo {C,CPP,CXX,CCAS,F,FC,LD}FLAGS > } > > # {C,CXX,F,FC}FLAGS that we allow in strip-flags This has been committed to the tree. filter-flags() should now include CCASFLAGS. @Tommy, its working at my end with the multilib portage and valgrind-3.7.0-r3. Please reopen this if it is still a problem, but I think we nailed it. Thanks for the report! |