This regression has been fixed in gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52355
Now bluez builds fine at least with gcc 4.7.0-RC-20120302 and this issue
should not be a problem for gcc 4.7.0 release. Thanks to Fedora people
who were the first to escalate the issue upstream.
** Bug watch
This looks correct to me. i requires the operand to be a compile-time
constant. In general, the memory location of a multi-dimensional array in C
isn't constant at compile-time. Now, as it happens, for ((char *)
sb_sample_f[1][0][0] - (char *) sb_sample_f[0][0][0]) to be particularly
** Changed in: bluez (Ubuntu)
Status: New = In Progress
** Changed in: bluez (Ubuntu)
Importance: Undecided = Medium
** Changed in: bluez (Ubuntu)
Assignee: (unassigned) = Mathieu Trudel-Lapierre (mathieu-tl)
--
You received this bug notification because you are a member of
This bug was fixed in the package bluez - 4.96-3ubuntu5
---
bluez (4.96-3ubuntu5) precise; urgency=low
* debian/patches/sbc_mmx.patch: fix a FTBFS due to new checks in GCC 4.7 for
inline assembly. (LP: #911871)
-- Mathieu Trudel-Lapierre mathieu...@ubuntu.com Thu, 05 Jan
I'm so absolutely not sure of my fix it's not even funny. Well, it does
seem to allow bluez to compile with gcc 4.7and I'm not seeing playback
issues yet in testing (which is what this looks like should be
affecting).
** Patch added: sbc_mmx.patch
** Tags added: patch
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/911871
Title:
FTBFS on amd64, i386 for test-rebuild-20111222 (gcc-4.7)
To manage notifications about this bug go to:
