Summary: | media-libs/libreplaygain-465: CFLAGS ignored (breaking multilib/etc... builds) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | stefan.demharter |
Component: | [OLD] Unspecified | Assignee: | Gentoo Sound Team <sound> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | binki, esigra |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 306835 |
Description
stefan.demharter
2010-11-24 23:07:05 UTC
show the actual compile lines failing. the multilib cflags must be passed to gcc via the cmdline and not through the env/gcc-config. The problematic compile line, which fetches the 64-bit object from ccache instead of creating a new 32-bit one (obtained with MAKEOPTS="VERBOSE=1" emerge =libreplaygain-465): cd /var/tmp/portage/media-libs/libreplaygain-465/work/libreplaygain-465_build/src && /usr/lib/ccache/bin/x86_64-pc-linux-gnu-gcc -Dreplaygain_shared_EXPORTS -DNDEBUG -O3 -fomit-frame-pointer -pipe -fPIC -I/var/tmp/portage/media-libs/libreplaygain-465/work/libreplaygain-465/include -o CMakeFiles/replaygain-shared.dir/gain_analysis.o -c /var/tmp/portage/media-libs/libreplaygain-465/work/libreplaygain-465/src/gain_analysis.c CFLAGS env variable (obtained with strace): CFLAGS=-march=core2 -msse -msse2 -msse3 -msse4 -mcx16 -mpopcnt -msahf -O2 -pipe -m32 that gcc is not being executed with -m32. not a bug in ccache. sound herd: you need to fix libreplaygain to pass -m32 for the 32-bit multilib compile. I don't understand why the problem should be with libreplaygain. As mentioned in my first post a workaround is to use CCACHE_NODIRECT=1. With that flag set libreplaygain builds correctly. So there is a problem with the direct mode of ccache, isn't it? (In reply to comment #5) > I don't understand why the problem should be with libreplaygain. > As mentioned in my first post a workaround is to use CCACHE_NODIRECT=1. With > that flag set libreplaygain builds correctly. So there is a problem with the > direct mode of ccache, isn't it? The problem was that libreplaygain was ignoring users' CFLAGS. I tried to reproduce this bug, but it was fixed by http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/media-libs/libreplaygain/libreplaygain-465.ebuild?r1=1.2&r2=1.3 . Please close this bug against libreplaygain and fix the summary to show that the problem was libreplaygain not respecting users' CFLAGS. The reason that this worked without ccache, as mike pointed out in comment 1, is that for ABI=x86, gcc was producing 32-bit code even though -m32 was not being passed to gcc. This is done through mysterious (and deprecated?) mechanisms in gcc-config/binutils-config. The reason that this didn't work with ccache is that ccache does not see these mysterious mechanisms through which gcc-config adds CFLAGS to gcc's command-line because the invocation order is ccache-wraper -> gcc-config -> gcc. For this bug to be ``fixed'' in the way that the reporter requested it to be fixed, the invocation order would have to be gcc-config -> ccache-wraper -> gcc -- which makes no sense to me and probably would cause more trouble. |