Hi@all, I having a problem compiling d-bus for ARM. I'm using scratchbox for that task. Maybe it is a similar problem like Bug Nr. 18205. When I try to start the configure script for d-bus I get some errors like: checking size of char... 0 checking size of short... 0 checking size of long... 0 checking size of int... 0 ... checking 32-bit integer type... configure: error: No 32-bit integer type found Seems that anything with the types goes wrong here. Would be nice if you could fix that. Software to verify: diablo-Maemo-sdk 4.1 and scratchbox. Thanks in advance, Jo
These are completely generic autoconf checks that any package using autoconf would have, afaik. Or at least any package using whichever generic autoconf macro we are using. In any case, pretty sure none of us copied on the bug know a thing about scratchbox or arm, so someone who does will need to figure this out. I seriously doubt it is a dbus bug, though.
Do you have a config.log file? and what CFLAGS settings did you try? Are you cross-compiling?
Created attachment 22341 [details] Config.log compiling d-bus 1.2.12 on arm
(In reply to comment #2) > Do you have a config.log file? Yes, I attached the config.log file. > and what CFLAGS settings did you try? Since I use scratchbox I usually do not need to set any additional CFLAGS. Usually Scratchbox handles all that stuff for me. > Are you cross-compiling? Yes. I'm cross compiling for ARM with a special toolchain. But to provide a testcase for you, I tried also to compile with diablo-Maemo-sdk 4.1. They are also using scratchbox. There was the same error. I also tried to compile dbus 1.0.2. This works well. With both toolchains.
From config.log I extracted this: configure:21496: checking size of short configure:21801: gcc -o conftest -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wdeclaration-after-statement -fno-common -Wno-unused -Wno-sign-compare -Wno-pointer-sign -Wno-format -fno-strict-aliasing conftest.c >&5 cc1: error: unrecognized command line option "-Wno-pointer-sign" configure:21805: $? = 1 configure: program exited with status 1 configure: failed program was: Seems like scratchbox sends CFLAGS that doesn't work on the given version of gcc ?
We enable -Wno-pointer-sign and a few other switches, which we don't check if the compiler supports or not.
-Wno-pointer-sign is now conditional, so this specific case shouldn't be a problem any more; dropping severity but leaving the bug open.
*** Bug 36850 has been marked as a duplicate of this bug. ***
Created attachment 46496 [details] [review] [PATCH 1/5] Import tp-compiler-flag.m4 and tp-compiler-warnings.m4 from telepathy-glib
Created attachment 46497 [details] [review] [PATCH 2/5] Use TP_COMPILER_WARNINGS for all -Wfoo options This consistently checks whether all these options actually work in the current version of gcc.
Created attachment 46498 [details] [review] [PATCH 3/5] Use TP_ADD_COMPILER_FLAG to simplify application of warning-like CFLAGS This also means we check for support for them.
Created attachment 46499 [details] [review] [PATCH 4/5] When checking for va_copy, use AC_LANG_SOURCE to shut up recent autoconf
Created attachment 46500 [details] [review] [PATCH 5/5] When checking for __sync_sub_and_fetch, don't underquote, to shut up recent autoconf Without the correct number of levels of quoting, autoconf mistakenly believes we didn't use AC_LANG_SOURCE where required. (In fact, AC_LANG_PROGRAM calls AC_LANG_SOURCE.)
(In reply to comment #10) > Created an attachment (id=46497) [details] > [PATCH 2/5] Use TP_COMPILER_WARNINGS for all -Wfoo options > > This consistently checks whether all these options actually work in the > current version of gcc. Side benefit: this checks for -Wwhatever with any compiler, on the assumption that they have (something resembling) their gcc meaning; this means we should get those warnings with, say, Intel cc (which iirc has a deliberately gcc-like command-line syntax).
These patches all look good to me.
Fixed in git for 1.4.10, 1.5.2 (and I think it's probably about time I did some releases...)
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.