I've tried to compile dbus 1.4.0 and 1.3.1 from source tarball (with expat-2.0.1 library also compiled from sources, if that matters) on a freshly-installed 64-bit FreeBSD 7.2 machine. Output from gcc --version and uname -a: gcc (GCC) 4.2.1 20070719 [FreeBSD] FreeBSD 7.2-RELEASE FreeBSD 7.2-RELEASE #0: Fri May 1 07:18:07 UTC 2009 root@driscoll.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 ./configure && make V=1 fails, printing these messages: /bin/sh ../libtool --tag=CC --mode=link gcc -ffunction-sections -fdata-sect ions -g -O2 -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wdeclaration-after-statement -fno -common -Wno-unused -Wno-sign-compare -Wno-pointer-sign -fno-strict-aliasing -W l,--gc-sections -pie -Wl,-z,relro -o dbus-daemon dbus_daemon-activation.o dbu s_daemon-bus.o dbus_daemon-config-parser.o dbus_daemon-config-parser-common.o dbus_daemon-connection.o dbus_daemon-desktop-file.o dbus_daemon-dir-watch-kqueu e.o dbus_daemon-dispatch.o dbus_daemon-driver.o dbus_daemon-expirelist.o dbus_ daemon-policy.o dbus_daemon-selinux.o dbus_daemon-services.o dbus_daemon-signa ls.o dbus_daemon-test.o dbus_daemon-utils.o dbus_daemon-config-loader-expat.o d bus_daemon-main.o ../dbus/libdbus-internal.la -lexpat -lpthread -lrt libtool: link: gcc -ffunction-sections -fdata-sections -g -O2 -Wall -Wchar-subsc ripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-ari th -Wcast-align -Wdeclaration-after-statement -fno-common -Wno-unused -Wno-sign- compare -Wno-pointer-sign -fno-strict-aliasing -Wl,--gc-sections -pie -Wl,-z -Wl ,relro -o dbus-daemon dbus_daemon-activation.o dbus_daemon-bus.o dbus_daemon-con fig-parser.o dbus_daemon-config-parser-common.o dbus_daemon-connection.o dbus_da emon-desktop-file.o dbus_daemon-dir-watch-kqueue.o dbus_daemon-dispatch.o dbus_d aemon-driver.o dbus_daemon-expirelist.o dbus_daemon-policy.o dbus_daemon-selinux .o dbus_daemon-services.o dbus_daemon-signals.o dbus_daemon-test.o dbus_daemon-u tils.o dbus_daemon-config-loader-expat.o dbus_daemon-main.o ../dbus/.libs/libdb us-internal.a /usr/local/lib/libexpat.so -lpthread -lrt -Wl,-rpath -Wl,/usr/loca l/lib -Wl,-rpath -Wl,/usr/local/lib /usr/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/crt1.o: could not read symbols: Bad value The problem is with -pie flag. Even though gcc accepts it, it's not really supported in my build environment: $ echo 'int main() { return 0; }' >foo.c; gcc -fPIC -pie -o foo foo.c /usr/bin/ld: /usr/lib/crt1.o: relocation R_X86_64_32 can not be used when making a shared object; recompile with -fPIC /usr/lib/crt1.o: could not read symbols: Bad value
That means you should fix your toolchain instead. GCC shouldn't accept options that don't work. Either the option should work, or it should be removed/disabled.
Yes, I agree, but that's the toolchain that shipped with this FreeBSD release. (And I suspect the situation is the same on FreeBSD 6.x-7.1). I can't easily fix it. It should be easy to add to Configure.in a check that verifies that gcc is capable of build executables with -pie option. Why don't you want to add it?
dbus' configure.in doesn't properly check that -pie is supported (it only checks for -fPIE flag), so I have to disagree with your assessment that it's "NOT-OUR-BUG", and reopen it. Look how another respectable open-source project checks for -pie: http://svn.apache.org/viewvc/httpd/httpd/trunk/configure.in?view=markup (search for "ap_cv_cc_pie"). Please, integrate that check in your configure.in.
Patches are accepted.
It would also be good to make PIE optional. In Maemo it's patched out of configure.in altogether[1], because on (some version of?) their ARM toolchain, it produces/produced executables that usually work, but not reliably (which we can't really check in configure). Debian has also had problems with PIE on various less mainstream architectures at various times (at least mips[2], hppa/m68k[3], avr32[4]). Debian's dbus is currently compiled with PIE on those architectures, though. If we add a --disable-pie option, distros with known-unreliable PIE support in (some of) their toolchains can at least use it as a workaround (for particular architectures or globally) without having to patch configure. [1] http://maemo.gitorious.org/maemo-gnome-essentials/dbus/blobs/maemo/debian/patches/80-remove-fpie-pie.patch which fixes NB#171940, according to debian/changelog [2] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=526961 [3] http://wiki.debian.org/Hardening#DEBBUILDHARDENINGPIE.28gcc.2BAC8-g.2B-.2B--fPIE-pie.29 [5] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=574716
*** This bug has been marked as a duplicate of bug 16621 ***
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.