dBus won't compile without -FPic added to CFLAGS on amd64. I only tried on an amd64 platform, so I cannot talk about other arches, but when keeping all the other Bug-Reports about this Topic in mind I think only 64-Bit-Platforms are affected. I assume, that not only the version I tried - dbus 0.23.4 is affected - is affected by this. Reproducible: Always Steps to Reproduce: 1. merge dbus without -fPic added to your CFLAGS 2. 3.
please append emerge info, it compiles fine here
pleave provide the output of 'emerge info' and additionally , the emerge log. it works fine for me
emerge info Portage 2.0.51.19 (default-linux/amd64/2005.0, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.11-gentoo x86_64) ================================================================= System uname: 2.6.11-gentoo x86_64 AMD Athlon(tm) 64 Processor 3200+ Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Mar 3 2005, 23:29:07)] distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] ccache version 2.4 [enabled] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.6.3, 1.7.9-r1, 1.4_p6, 1.8.5-r3, 1.9.5 sys-devel/binutils: 2.15.92.0.2-r7 sys-devel/libtool: 1.5.14 virtual/os-headers: 2.6.8.1-r4 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-mtune=athlon64 -march=athlon64 -mfpmath=sse -m64 -O2 -pipe" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib/mozilla/defaults/pref /usr/share/config /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-mtune=athlon64 -march=athlon64 -mfpmath=sse -m64 -O2 -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distcc distlocks sandbox" GENTOO_MIRRORS="ftp://mirror.switch.ch/mirror/gentoo ftp://ftp.solnet.ch/mirror/gentoo http://mirror.switch.ch/ftp/mirror/gentoo http://gentoo.mirror.solnet.ch http://gentoo.osuosl.org http://www.ibiblio.org/pub/Linux/distributions/gentoo" LANG="de_DE@euro" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/tmp/tmp_portage" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="amd64 X aac acl acpi alsa artworkextra avi berkdb bitmap-fonts bzip2 caps ccache cdr crypt cups directfb dmx dvdr dvdread ecc eds esd exif fam fbcon ffmpeg font-server fortran ftp gcj gif gimp gnome gnomedb gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal iconv icu idea imagemagick imlib intl ipv6 jabber jack jack-tmpfs java javascript jp2 jpeg kerberos krb4 ldap libwww lzw lzw-tiff mad md5sum mdb mime mozilla mp3 mpeg ncurses nls nntp nptl nptlonly oav objc opengl openssh oss pam pdflib perl png portaudio python quicktime readline real samba scanner spell ssl tcpd threads tiff truetype truetype-fonts type1-fonts unicode usb userlocales xfs xine xinerama xml xml2 xmms xpm xprint xrandr xv xvid yahoo zlib" Unset: ASFLAGS, CBUILD, CTARGET, LC_ALL, LDFLAGS -- Compile-Error-Message follows --
Compilling stops with following message: ---------------------------------------------- relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/dbus-address.o: could not read symbols: Bad value collect2: ld returned 1 exit status distcc[11197] ERROR: compile (null) on localhost failed ---------------------------------------------- When searching for fPIC @ bugs.gentoo.org you can find several bugs about the same thing conerning other libs / apps. I also found this statement: ---------------------------------------------- I have an alpha, but I would be surprised if it isn't a problem on all 64bit platforms. For libraries alpha requires -fPIC to be able to move code around in memory. at least for shared libraries. (*.so stuff) Notable exeption seems to be the plain old libraries. At least when libtool is used to build stuff the --dynmaics are almost allways compiled with -fPIC -DPIC added to the CFLAGS. ---------------------------------------------- It's from bug#37719 > http://bugs.gentoo.org/show_bug.cgi?id=37719 <
Would I run into other troubles when simply adding "-fPIC" to CFLAGS in my make.conf?
putting -fPIC into your CFLAGS is a pretty bad idea, it slows down your binaries (no penalty on shared libraries however). please always file a bug instead, CFLAGS="-fPIC" is nothing than a hack'ish work-around.
sorry, i wasn't able to reproduce this, although i also run a testing system. could you please give a few more lines, i.e. from the command line before the ones you pasted to the !!! lines?
Here are some additional lines: -------------------------------------- x86_64-pc-linux-gnu-ar cru .libs/libdbus-convenience.a .libs/dbus-address.o .libs/dbus-auth.o .libs/dbus-auth-script.o .libs/dbus-bus.o .libs/dbus-connection.o .libs/dbus-errors.o .libs/dbus-keyring.o .libs/dbus-message.o .libs/dbus-object-tree.o .libs/dbus-pending-call.o .libs/dbus-resources.o .libs/dbus-server.o .libs/dbus-server-debug-pipe.o .libs/dbus-server-unix.o .libs/dbus-sha.o .libs/dbus-test.o .libs/dbus-timeout.o .libs/dbus-threads.o .libs/dbus-transport.o .libs/dbus-transport-unix.o .libs/dbus-watch.o .libs/dbus-dataslot.o .libs/dbus-hash.o .libs/dbus-internals.o .libs/dbus-list.o .libs/dbus-marshal.o .libs/dbus-memory.o .libs/dbus-mempool.o .libs/dbus-message-builder.o .libs/dbus-spawn.o .libs/dbus-string.o .libs/dbus-sysdeps.o .libs/dbus-userdb.o .libs/dbus-mainloop.o x86_64-pc-linux-gnu-ranlib .libs/libdbus-convenience.a creating libdbus-convenience.la (cd .libs && rm -f libdbus-convenience.la && ln -s ../libdbus-convenience.la libdbus-convenience.la) /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/dbus-address.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC .libs/dbus-address.o: could not read symbols: Bad value collect2: ld returned 1 exit status distcc[4154] ERROR: compile (null) on localhost failed make[3]: *** [libdbus-1.la] Fehler 1 make[3]: Leaving directory `/tmp/tmp_portage/portage/dbus-0.23.4/work/dbus-0.23.4/dbus' make[2]: *** [all] Fehler 2 make[2]: Leaving directory `/tmp/tmp_portage/portage/dbus-0.23.4/work/dbus-0.23.4/dbus' make[1]: *** [all-recursive] Fehler 1 make[1]: Leaving directory `/tmp/tmp_portage/portage/dbus-0.23.4/work/dbus-0.23.4' make: *** [all] Fehler 2 !!! ERROR: sys-apps/dbus-0.23.4 failed. !!! Function src_compile, Line 105, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message. -------------------------------------- Today is the first time, that this happens so often. Nearly every app is affected (mainly libs). So let's remember what I changed: - Upgraded 2004.3 -> 2005.0 - Added nptlonly to my USE-Flags and recompiled glibc - Upgraded 2.6.11-gentoo -> 2.6.11-gentoo-r4 (only disabled rivafb - rest of config didn't change) Could those to things have to do with the problem? I don't think it's the kernel, so it must be glibc / nptlonly. I'll give it a try tomorrow or so.
> Today is the first time, that this happens so often. Nearly every app is affected (mainly libs). Before I had that problem only once, but I can't remember which ebuild was affected.
This hits me too. I fixed it by adding 'use amd64 && append-flags -fPIC' to the ebuild (as well as inherit flag-o-matic) This affects dbus-0.23.4 and dbus-0.23-r3, but it seems to hit only when running 2005.0. They merged fine under 2004.3. Any clue?
I have been using dbus myself for a week or so, and it compiles/installs fine. I have been using the 2005.0 profile for much longer - and have just recompiled sys-apps/dbus-0.23.4 without any issues or need for -fPIC, which certainly should not be added to CFLAGS.
Bug 37719 is quite outdated ... requiring PIC isnt bitsize related (64 vs 32) that said, doing `append-flags -fPIC` is rarely correct ... and dbus works just fine for me on amd64 w/out -fPIC in CFLAGS
please run `emerge dbus >& log` and post the log as an attachment it looks like your libtool may be broken ... perhaps try re-emerging it ?
Got it! The culprit was LDFLAGS='-L/emul/linux/x86/usr/lib' CFLAGS="$CFLAGS -Wl,-L/emul/linux/x86/usr/lib" in make.conf. (Yes, I know that's broken. Better ideas?) Anyway, I'll play with libtool to see if I can figure out what that broke it.
I also changed the ebuild to use -fPIC on amd64 and already wanted to upload my version, but then I noticed "putting -fPIC into your CFLAGS is a pretty bad idea, it slows down your binaries (no penalty on shared libraries however). please always file a bug instead, CFLAGS="-fPIC" is nothing than a hack'ish work-around." this comment. Seems that I'm not the only one being affected and I assume it's not an package-specific problem, because many packages are broken after 2005.0 upgrade... I'll add the emerge output later.
*** Bug 87131 has been marked as a duplicate of this bug. ***
*** Bug 87135 has been marked as a duplicate of this bug. ***
*** Bug 87150 has been marked as a duplicate of this bug. ***
*** Bug 87152 has been marked as a duplicate of this bug. ***
Created attachment 54870 [details] dbus_merge.log
checking for x86_64-pc-linux-gnu-gcc option to produce PIC... -fPIC checking if x86_64-pc-linux-gnu-gcc PIC flag -fPIC works... no checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o... no something is wrong on your system please post the config.log from the build dir as an attachment
Created attachment 54920 [details] config.log
Try removing -m64 from your CFLAGS.
Removing -m64 from CFLAGS works, but isn't this flag needed for creating 64bit-Code? Will I still get 64bit-Code? And the thing I'm wondering of the whole time: This flag didn't result in any problems while running 2004.3. I never had any problems with this flag. They started after upgrading to 2005.0. WHY?
gcc will create 64bit code by default unless you explicitly overide it with -m32, so no need to add -m64. I assume this was not a problem before because you were using a -multilib gcc before the 2005.0 upgrade?
The flag is not needed for creating 64 bit code, and should not be set in your CFLAGS. -m32 and -m64 force the compiler to create 32 or 64 bit objects, but as you are using GCC on an amd64 install it defaults to producing -m64, so this is not needed and in fact breaks some ebuilds which use -m32 to produce 32 bit code. I hope this makes it a little clearer. You will still get 64 bit code - I have never had -m64 in my CFLAGS and my system is still 64 bit.
My System has always been multilib enabled! Even in 2004.3. But it seems impossible to use multilib ind 2005.0: Since ever "multilib" is part of my USE-Variabel. E.g. the command emerge -pv gcc gave me the following output: +multilib (red) now I only see (-multilib). The brackets show me, that this USE-Flag ist fixed (by Profile). But it has a minux in it, so it's not enabled?. I assume it should be (+multilib).
You misunderstand the profile. 2005.0 has multilib on by default - it cannot be turned off without switching to the no-multilib profile. You are running a multilib system if you are using the 2005.0 default profile. So the USE flag is disabled, and this does look a little misleading as it is diabled -, but just means that the USE flag has no affect in this case. We have been taking a look at the config.log, and these lines are what is probably causing the issues due to you having -m64 in your CFLAGS, configure:6905: checking if x86_64-pc-linux-gnu-gcc static flag works /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. configure:6928: result: no configure:6946: checking if x86_64-pc-linux-gnu-gcc supports -fno-rtti -fno-exceptions configure:6964: x86_64-pc-linux-gnu-gcc -c -mtune=athlon64 -march=athlon64 -mfpmath=sse -m64 -O2 -pipe -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -fno-rtti -fno-exceptions conftest.c >&5 /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. cc1: warning: command line option "-fno-rtti" is valid for C++/ObjC++ but not for C configure:6968: $? = 0 configure:6979: result: no configure:6994: checking for x86_64-pc-linux-gnu-gcc option to produce PIC configure:7171: result: -fPIC configure:7179: checking if x86_64-pc-linux-gnu-gcc PIC flag -fPIC works configure:7197: x86_64-pc-linux-gnu-gcc -c -mtune=athlon64 -march=athlon64 -mfpmath=sse -m64 -O2 -pipe -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -fPIC -DPIC conftest.c >&5 /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. configure:7201: $? = 0 configure:7212: result: no configure:7236: checking if x86_64-pc-linux-gnu-gcc supports -c -o file.o configure:7257: x86_64-pc-linux-gnu-gcc -c -mtune=athlon64 -march=athlon64 -mfpmath=sse -m64 -O2 -pipe -Wall -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wfloat-equal -Wsign-compare -o out/conftest2.o conftest.c >&5 /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/lib/distcc/bin/x86_64-pc-linux-gnu-gcc: -m64 detected on the command line overrides implicit -m64 added by the wrapper. /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.3-20050110/x86_64-pc-linux-gnu-gcc: gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper. configure:7261: $? = 0 configure:7281: result: no So these tests are failing when they should not be, due to messages from the gcc wrapper. You should remove -m64 from your CFLAGS, but this issue will need to be looked at more closely.
OK. Thanks! I'd have set resolution to FIXED, because for me everything works fine now, but since you wrote "this issue will need to be looked at more closely" I won't change anything.
ok, lesson here is, dont try to be smarter than your compiler ;)
Sorry, I made a big mistake: I copied the command line from clipboard, so it happend, that i used the following > CFLAGS="-mtune=athlon64 -march=athlon64 -mfpmath=sse -O2 -pipe -fPIC" CXXFLAGS="-mtune=athlon64 -march=athlon64 -mfpmath=sse -O2" -pipe -fPIC" emerge dbus I only removed the -m64 flag and I forgot to remove -fPIC. Sorry. I reopend the bug.
I finally got it to work. Indeed it's the -m64 flag's fault. Removing -m64 from the CFLAG-Variable doesn't change anything since ist also set in make.profile/make.default. The Variable in make.defaults is called CFLAGS_amd4. Removing -m64 from this Variable solves the problem. But i dunno if that's such a good solution, since someone must have thought something when adding this to make.defaults.
In my last answer there are to misspellings: - It should always be make.defaults and not make.default or sth. else. - The Variable in make.defaults is called CFLAGS_amd64 Will my change to make.defaults be overriden with every "emerge sync"?
The warning message was removed in the development 1.4.0 version (don't use it), and I've removed it now from 1.3.10-r2 as well, but you should really NOT put stuff like that in your own CFLAGS ;) Phillip, make.defaults is in your profile dir, so yes, it'll get overwritten when you sync. If youu want to override something in make.defaults, put it in /etc/make.conf
But how can I unset an CFLAG, that is set in make.defaults? Even if I don't set -m64 by hand it is set in make.defaults and I do have the problem. >The warning message was removed in the development 1.4.0 version (don't use it), and I've removed it now from 1.3.10-r2 as well Does this mean I can use the original Version of make.defaults which will add -m64 to CFLAGS?
I merged gcc-config-1.3.10-r2 and the problem is finally solved. Even with -m64 set due to make.defaults there are no more problems. Thanks.
I am sorry to say this but I got a similar problem (see bug #87546) and I did not have the -m64 flag. Nevertheless, I do get the same distcc error message: distcc[11197] ERROR: compile (null) on localhost failed
The distcc-ERROR is OK. Are you using 2005.0? Then you do have the -m64 Flag enabled by default. Except when using no-multilib-profil. The solution is to remerge gcc-config 1.3.10-r2 or 1.4.0. In there the warning of the gcc-wrapper ("gcc-wrapper: -m64 detected on the command line overrides implicit -m64 added by the wrapper.") is removed. The warning confuses Configure.
*** Bug 95842 has been marked as a duplicate of this bug. ***
