ofono build error on ARM
Hi,
I'm seeing the following build error when building ofono on an HTC G1 phone:
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -g -O2 -g -Werror -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wdeclaration-after-statement -Wmissing-declarations -Wredundant-decls -Wcast-align -MT netlink.lo -MD -MP -MF .deps/netlink.Tpo -c netlink.c -fPIC -DPIC -o .libs/netlink.o
cc1: warnings being treated as errorsnetlink.c: In function ‘g_pn_nl_process’:
netlink.c:75: error: cast increases required alignment of target type netlink.c:107: error: cast increases required alignment of target type netlink.c:109: error: cast increases required alignment of target type make[2]: *** [netlink.lo] Error 1
This is on a Debian lenny system. The code in question is (for example):
for (rta = IFA_RTA(ifa);
Which expands to:
for (rta =
((struct rtattr*) ( ((char*)(ifa)) + ( ((sizeof(struct ifaddrmsg))+4 -1) & ~(4 -1) ))) ;
I believe the compiler is not liking the cast from char* to rtattr*, but I'm not certain.
gcc info:
localhost:~/ofono# gcc -v Using built-in specs. Target: arm-linux-gnueabi Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1)
localhost:~/ofono# cat /proc/cpuinfo Processor : ARMv6-compatible processor rev 2 (v6l) BogoMIPS : 383.38 Features : swp half thumb fastmult edsp java CPU implementer : 0x41 CPU architecture: 6TEJ CPU variant : 0x1 CPU part : 0xb36 CPU revision : 2 Cache type : write-back Cache clean : cp15 c7 ops Cache lockdown : format C Cache format : Harvard I size : 32768 I assoc : 4 I line length : 32 I sets : 256 D size : 32768 D assoc : 4 D line length : 32 D sets : 256
Hardware : trout
Revision : 0080
Serial : 0000000000000000
Quoted 12 lines · On Fri, 31 Jul 2009 11:13:10 -0400 Andres Salomon <[email protected]>…
Hi,
I'm seeing the following build error when building ofono on an HTC G1 phone:
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/glib-2.0
(quoted diff) +0
-5-I/usr/lib/glib-2.0/include -g -O2 -g -Werror -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wdeclaration-after-statement -Wmissing-declarations -Wredundant-decls -Wcast-align -MT netlink.lo -MD -MP -MF .deps/netlink.Tpo -c netlink.c -fPIC -DPIC -o .libs/netlink.o
Quoted 7 lines
cc1: warnings being treated as errors
netlink.c: In function ‘g_pn_nl_process’:
netlink.c:75: error: cast increases required alignment of target type netlink.c:107: error: cast increases required alignment of target type netlink.c:109: error: cast increases required alignment of target type make[2]: *** [netlink.lo] Error 1
Note that building the file without -Wcast-align fixes the issue. Perhaps just that single file should be built without cast alignment checking?
Le vendredi 31 juillet 2009 18:13:10 Andres Salomon, vous avez écrit :
Quoted 12 lines
Hi,
I'm seeing the following build error when building ofono on an HTC G1 phone:
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/glib-2.0
(quoted diff) +0
-5-I/usr/lib/glib-2.0/include -g -O2 -g -Werror -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wdeclaration-after-statement -Wmissing-declarations -Wredundant-decls -Wcast-align -MT netlink.lo -MD -MP -MF .deps/netlink.Tpo -c netlink.c -fPIC -DPIC -o .libs/netlink.o
Quoted 6 lines
cc1: warnings being treated as errors
netlink.c: In function ‘g_pn_nl_process’:
netlink.c:75: error: cast increases required alignment of target type netlink.c:107: error: cast increases required alignment of target type netlink.c:109: error: cast increases required alignment of target type make[2]: *** [netlink.lo] Error 1
I think there is no way to fix this. It comes from the Netlink packet format and macros, which are confusing gcc. That's why I hate to enfore -Werror.
Signature · 2 lines
Rémi Denis-Courmont http://www.remlab.net/
Hi Remi,
Quoted 10 lines
Quoted 10 lines
I'm seeing the following build error when building ofono on an HTC G1 phone:
gcc -DHAVE_CONFIG_H -I. -I.. -I/usr/include/glib-2.0
(quoted diff) +0
-5-I/usr/lib/glib-2.0/include -g -O2 -g -Werror -Wextra -Wno-unused-parameter -Wno-missing-field-initializers -Wdeclaration-after-statement -Wmissing-declarations -Wredundant-decls -Wcast-align -MT netlink.lo -MD -MP -MF .deps/netlink.Tpo -c netlink.c -fPIC -DPIC -o .libs/netlink.o
Quoted 9 lines
Quoted 6 lines
cc1: warnings being treated as errors
netlink.c: In function ‘g_pn_nl_process’:
netlink.c:75: error: cast increases required alignment of target type netlink.c:107: error: cast increases required alignment of target type netlink.c:109: error: cast increases required alignment of target type make[2]: *** [netlink.lo] Error 1I think there is no way to fix this. It comes from the Netlink packet format and macros, which are confusing gcc. That's why I hate to enfore -Werror.
we only enforce -Werror for the developers and it is important to have gcc help us catch mistakes that might be easily overlooked. I would have to look into these one and how we can fix them properly.
Regards
Marcel
Le samedi 1 août 2009 18:06:49 Marcel Holtmann, vous avez écrit :
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
cc1: warnings being treated as errors
netlink.c: In function ‘g_pn_nl_process’:
netlink.c:75: error: cast increases required alignment of target type netlink.c:107: error: cast increases required alignment of target type netlink.c:109: error: cast increases required alignment of target type make[2]: *** [netlink.lo] Error 1
Quoted 6 lines
Quoted 3 lines
I think there is no way to fix this. It comes from the Netlink packet format and macros, which are confusing gcc. That's why I hate to enfore -Werror.
we only enforce -Werror for the developers and it is important to have gcc help us catch mistakes that might be easily overlooked.
If I recall correctly, `-Werror' is enforced when maintainer mode is enabled. Really, turning off maintainer mode is primilarly useful to binary package maintainers who *might* not want to trigger autotools updates. Then again, some might waht to have them anyway... I find the underlying assumption to be a bit restrictive if not flawed.
Quoted 1 line
I would have to look into these one and how we can fix them properly.
As far as I understand, those warnings come from casting receive buffers into structure with higher-order alignment requirement - with some of your competitors' CPU architectures anyway ;) Arguably, those are caused by kernel/libc headers, not Ofono. I will check on Monday if we can fix them by promoting the receive buffers to larger integer types, but it might make the code worse.
But generally, there remain a problem that some warnings might simply be bogus, or not under our control. For instance -outside of Ofono- I'm yet to find a way around dummy variable "clobber warnings" when using POSIX thread cancellation cleanup handlers. Sure, I could make all variables volatile, but I refuse to damage optimizations for the sake of bogus warnings...
The real shame is that -Werror-* is dysfunctional in GCC :(
Signature · 2 lines
Rémi Denis-Courmont http://www.remlab.net/
Quoted 5 lines · Rémi Denis-Courmont
As far as I understand, those warnings come from casting receive buffers into structure with higher-order alignment requirement - with some of your competitors' CPU architectures anyway ;) Arguably, those are caused by kernel/libc headers, not Ofono. I will check on Monday if we can fix them by promoting the receive buffers to larger integer types, but it
might
Quoted 1 line
make the code worse.
Nope. The problem is that netlink is internally casting pointers to char* for arithmetic operation, and then back to struct whatever. This confuses gcc, even though it should be a non-issue at run-time.
Signature · 1 line
Rémi Denis-Courmont