gcc was compiled with -fPIC. ~amd64 was added kde-base/arts-3.4.0_beta1 +alsa +arts +artswrappersuid -debug +esd -hardened +jack +mad +oggvorbis -xinerama Reproducible: Always Steps to Reproduce: 1. emerge kde Actual Results: /bin/sh ../libtool --silent --mode=link --tag=CXX x86_64-pc-linux-gnu-g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500-D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -DNDEBUG -DNO_DEBUG -O2 -O2 -march=athlon64-pipe -fPIC -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-exceptions -fno-check-new -fno-common-fvisibility=hidden -fvisibility-inlines-hidden -ftemplate-depth-99 -o libmcop.la -rpath /usr/kde/3.4/lib64 -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -version-info 1:0 -L/usr/lib64 -L/usr/kde/3.4/lib64 -L/usr/qt/3/lib64 -L/usr/lib64 -Wl,--as-needed -Wl,--enable-new-dtags buffer.lo connection.lo core.lo debug.lo dispatcher.lo iomanager.lo object.lo socketconnection.lo tcpconnection.lo unixconnection.lo tcpserver.lo unixserver.lo objectmanager.lo factory.lo idlfilereg.lo ifacerepo_impl.lo mcoputils.lo startupmanager.lo md5.lo md5auth.lo referenceclean.lo datapacket.lo asyncstream.lo notification.lo flowsystem.lo extensionloader.lo tmpglobalcomm.lo mcopconfig.lo connect.lo reference.lo type.lo trader_impl.lo dynamicrequest.lo anyref.lo loopback.lo delayedreturn.lo thread.lo dynamicskeleton.lo -lgmodule-2.0 -ldl -lgthread-2.0 -lglib-2.0 ../libltdl/libltdlc.la /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/core.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[3]: *** [libmcop.la] Error 1 make[3]: Leaving directory `/var/tmp/portage/arts-3.4.0_beta1/work/arts-1.3.91/mcop' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/arts-3.4.0_beta1/work/arts-1.3.91/mcop' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/arts-3.4.0_beta1/work/arts-1.3.91' make: *** [all] Error 2 !!! ERROR: kde-base/arts-3.4.0_beta1 failed. !!! Function kde_src_compile, Line 142, Exitcode 2 !!! died running emake, kde_src_compile:make Portage 2.0.51-r14 (default-linux/amd64/2005.0, gcc-3.4.3, glibc-2.3.4.20041102-r0, 2.6.10-ck4 x86_64) ================================================================= System uname: 2.6.10-ck4 x86_64 AMD Athlon(tm) 64 Processor 4000+ Gentoo Base System version 1.6.8 Python: dev-lang/python-2.3.4,dev-lang/python-2.4 [2.4 (#1, Dec 21 2004, 21:22:23)] ccache version 2.3 [enabled] dev-lang/python: 2.3.4, 2.4 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.5, 1.8.5-r2, 1.6.3, 1.4_p6, 1.7.9, 1.9.4 sys-devel/binutils: 2.15.92.0.2-r2, 2.15.92.0.2-r1 sys-devel/libtool: 1.5.10-r2 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CFLAGS="-O2 -march=athlon64 -pipe -fPIC" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /opt/openjms/config /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /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/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe -fPIC" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg candy ccache distlocks moo sandbox" GENTOO_MIRRORS="ftp://cs.ubishops.ca/pub/gentoo ftp://sunsite.ualberta.ca/pub/unix/Linux/gentoo/ ftp://gentoo.risq.qc.ca/ ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://mirror.tucdemonic.org/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage"
You are not alone.
If I'm not wrong I can understand that this problem is amd64 only. So I'll CC the amd64 herd, and feel free to reassign the bug to you. There's also a similare bug: #62419.
i reported this bug on kde's bugzilla
This isn't an upstream issue, it's a local compilation issue. I doubt the KDE developers are going to be able to help.
I have the same problem trying to compile KDE 3.4 from CVS sources.
Re: #4 you're right, they said it's a compiler error, i'm not sure what patch to gcc would cause it.
*** Bug 79690 has been marked as a duplicate of this bug. ***
toolchain herd: reassigning to you since we are seeing more and more of these errors or similar ones, can you see if there's something wrong with our libstdc++/binutils setup? Joseph: please post your 'emerge info'
Kugelfang and i are looking at this one at the moment, stay tuned.
*** Bug 79711 has been marked as a duplicate of this bug. ***
Consensus seems to be to remove -fvisibilit=hidden and -fvisibility-inlines-hidden with a specifically taylored gcc SPECS file. For this, see also "GCC-3.4, -fvisibility* and KDE/QT on amd64", mail on gentoo-dev mailing list.
*** Bug 77592 has been marked as a duplicate of this bug. ***
note that for bug 77592 the error is a bit different: "relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC"
Issue is mentioned upstream: http://groups.google.de/groups?q=relocation+R_X86_64_PC32+against+making+a+shared+object&hl=de&lr=&selm=ct12kj%242njo%241%40FreeBSD.csie.NCTU.edu.tw&rnum=2
http://dev.gentoo.org/~pappy/arts-vs-gcc-visibility/gentoo_toolchain.log our progress so far, thanks for the teams for working on this together. -Alex
Internal Problem Report regarding RELOCATION errors with PIC generated code: Any given CXXFLAGS containing -fvisibility-inlines-hidden and -fvisibility="hidden" being used by libtool to construct object files (ending with the extension .o) for building a statically linked shared library (ending with .a) and being also used for constructing this same object code with -fPIC leads to the linker emitting hard to understand errors about false relocations in the object files that are demonstrable and evidently created as -fPIC object code. This is due to a yet to be investigated strange and unwanted gcc behaviour. (this can be proven by adding -v to the CXXFLAGS of libtool) Danny worked out a solution to filter -fvisibility-inlines-hidden from all respective CXXFLAGS that are instrumented for generating such object code and can give a positive feedback and will trigger a wide range of testing plus notification of the appropriate upstream contacts about this issue. This is an issue of gcc generating incorrect object code that the linker cannot subsequently process into transforming this "malformed" object code into the contents a shared library. Thank you to the AMD team for your fast problem solution skills and help regarding this "deeper" problem in the gcc-3.4 toolchain. Danny is currently working on a solution regarding kde.eclass filtering this evil compiler flag out of possibly infected kde ebuilds. Thanks again for the good supprt and have fun with the (now a little more less broken) toolchain, Alex References: http://people.redhat.com/drepper/dsohowto.pdf
Created attachment 49689 [details, diff] Patch against kde.eclass to allow compilation of kde-3.4.0_beta1 on amd64 for the time being. This patch allows to build arts-3.4.0_beta1 and packagtes with similar problems. It removes the offending -fvisible-inlines-hidden flag from CXXFLAGS w/o touching the desired -fvisible=hidden.
Created attachment 49691 [details, diff] Patch against acinclude.m4 to possibly go upstream KDE-herd: Please review attached patch. The upstream KDE devs might want to include it until this gcc-{3.4,4.0} BUG vanishes.
Paolo Carlini from suse could confirm the problem for amd64, but neither on x86 nor on ia64. http://gcc.gnu.org/ml/libstdc++/2005-01/msg00302.html
Finally wrote a minimum failing example, it seems that the extern-template feature of gcc makes gcc break, see the bug report at gcc.gnu.org: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
It may be related to this change in binutils: http://sources.redhat.com/ml/libc-alpha/2004-12/msg00062.html Changes from binutils 2.15.91.0.1: 2. Fix the x86_64 linker to prevent non-PIC code in shared library.
The patch to kde.eclass can't be used as-is. If make -f admin/Makefile.common is triggered for whatever reason, changes to configure.in will be lost. We should rather modify all configure.in.in files in src_unpack. I'll attach a patch doing that. Other than that I'm OK with applying this. Anyone else? (I don't have an AMD64 to play with; I'm just commenting on the patch to kde.eclass.)
Created attachment 49805 [details, diff] Corrected patch to kde.eclass to disable VISIBILITY_HIDDEN on amd64 for all kde ebuilds
Are you talking about the acinclude.m4 patch, which avoids setting the -fvisiblity-inlines-hidden compiler flags, but which allows the HAVE_VISIBILITY to pass? In my opinion that feature should not be disabled in general. As you can read in the gcc bug report, the binutils do their job good, it is just gcc that defines bad symbols when the extern template feature is used, from what i know this is only used in the libstdc++-library. I would rather suggest to only remove the part that makes all inlines hidden no matter what general visibility is choseen. Kugelfangs patch worked fine here.
You're right, the acinclude.m4 patch is better if it suffices. Since the visibility thing is only used in KDE 3.4, which is masked, we can introduce this patch globally without much testing first. kugelfang: why did you make two patches, with the kde.eclass one removing all visibility functionality and the acinclude.m4 one removing only the problematic inlines flag? We can apply the acinclude.m4 patch globally if needed. amd64 people: OK to commit the patch to acinclude.m4 for all kde 3.4b1 ebuilds? AFAIK noone on the kde team has an amd64 box to test on.
Sorry, i forgot to mark my first patch as obsolete ;-) Can we patch acinclude.m4 from within kde.eclass, or will we have to patch all ebuilds manually ?
I've applied your patch to acinclude.m4.in from kde_src_unpack and committed the eclass. This should only affect kde 3.4 ebuilds on amd64. This is kde.eclass rev 1.110. I used a sed because a patch would have to go into all the digests.
From the gcc bug (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664), which was closed as INVALID: >> It is a compiler bug. VisTest<char>::VisTest() is never defined. >> R_X86_64_PC32 relocation may not reach it at runtime when it is >> called. The new linker catches this particular bug at linktime. > > Actually this is not a gcc or a linker bug but a programmers. > Basically -fvisibility=hidden -fvisibility-inlines-hidden says all I repeat > all functions (defined or not) as hidden. What does this mean for us, can anyone explain?
Gregorio: I cannot understand well that comment. It says that that flags make all the functions hidded, but this is normal as the kde developers exports only the externally needed functions (like is always done in ms windows.). Probably it's saying that something on the kde side isn't correctly exported? dunno.
the comment you quoted is wrong, they found the bug in the libstdc++ headers
*** Bug 80034 has been marked as a duplicate of this bug. ***
Shouldn't sys-devel/binutils-2.15.92.0.2-r1 be marked as ~amd64?
Removing pappy@g.o from CC: He has resigned as a Gentoo Developer. @Mike: According to LukeJr, the -fivisibility-* options are part of a backported patch and this BUG can by fixed by excluding these patches: 13_all_gcc34-visibility1.patch.bz2 14_all_gcc34-visibility2.patch.bz2 15_all_gcc34-visibility3.patch.bz2 Can we take them out and put 'em back in when upstream fixes it ?
Mandrakelinux 10.2 Beta1 for x86_64 was relased today. It contains a gcc 3.4 with backported symbol visibility patches, just like gentoo, and KDE is compiled with -fvisibility=hidden and -fvisibility-inlines-hidden according to the release notes. I wonder how they have managed to work around this problem! http://www.mandrakelinux.com/en/102beta-x86-64.php3
I guess they use an older, and less correct binutils packages. So this libstdc++ and gcc bug will not show up. Should we patch again, combinging the final result of [1], the patch at [2] and a patched libstdc++? [1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 [2] http://gcc.gnu.org/ml/gcc-patches/2005-02/msg01835.html Are there other packages than kde, that use -fvisibility?
*** Bug 84460 has been marked as a duplicate of this bug. ***
Acctually mandrake uses the same version of binutils that gentoo so I decided to investigate this a bit further. It seems that something is wrong with gentoo's symbol visibility patches. I replaced the patches with those from Mandrake and the problem disappeared. Now KDE 3.4-rc1 and 3.3 compiles without problems with -fvisibility-inlines-hidden on my amd64. I'm going to attatch an updated patch tarball with the mandrake patches. Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3, glibc-2.3.4.20050125-r0, 2.6.11-ck2 x86_64) ================================================================= System uname: 2.6.11-ck2 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.4.16 Python: dev-lang/python-2.3.4-r1 [2.3.4 (#1, Feb 20 2005, 21:53:44)] dev-lang/python: 2.3.4-r1 sys-devel/autoconf: 2.59-r6, 2.13 sys-devel/automake: 1.7.9-r1, 1.8.5-r3, 1.5, 1.4_p6, 1.6.3, 1.9.4 sys-devel/binutils: 2.15.94.0.2.2 sys-devel/libtool: 1.5.10-r4 virtual/os-headers: 2.6.8.1-r3 ACCEPT_KEYWORDS="amd64" AUTOCLEAN="yes" CFLAGS="-Os -march=athlon64 -pipe -fomit-frame-pointer -fweb" 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="-Os -march=athlon64 -pipe -fomit-frame-pointer -fweb -fvisibility-inlines-hidden -fno-enforce-eh-specs" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig ccache distlocks sandbox" GENTOO_MIRRORS="http://snigel.no-ip.com/ http://mirror.pudas.net/gentoo ftp://ftp.rhnet.is/pub/gentoo/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.rhnet.is/pub/gentoo/" LANG="sv_SE.ISO8859-1" LC_ALL="sv_SE.ISO8859-1" LDFLAGS="-Wl,-O1" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="amd64 X aalib acpi alsa artswrappersuid berkdb caps cdr crypt curl dga dvd dvdr dvdread eds f77 fam fbcon fortran gcj gif gnome gphoto2 gpm gtk gtk2 hal imlib ipv6 jack jack-tmpfs java javascript jp2 jpeg kdeenablefinal lzw lzw-tiff mad mikmod mng motif mozilla mp3 mpeg multilib ncurses nls nptl nptlonly nvidia objc offensive oggvorbis opengl pam perl pic png pnp python qt quicktime readline samba ssl svg tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales vidix xine xml xml2 xmms xpm xrandr xv xvid zlib video_cards_nvidia linguas_sv" Unset: ASFLAGS, CBUILD, CTARGET
Created attachment 53432 [details] Patch tarball. This is the updated patch tarball with the mandrake patches. I bumped the version to 1.2. I can't reproduce the bug with this.
gcc patch tarball ? which gcc version ?
Sorry. I'm using the latest stable, gcc 3.4.3-r1.
ok, i'll see about a 3.4.3-r2 then
*** Bug 85144 has been marked as a duplicate of this bug. ***
ok, danny and i both verified this works nicely, thanks Simon :) i'm going to add gcc-3.4.3.20050110-r1 with these fixes once i verify a few other patches work sanely ... should happen tomorrow or sunday at the latest
gcc-3.4.3.20050110-r1 now in portage, thanks all !
Hmm, am I missing something? gcc -shared -Wl,-soname -Wl,libnspr4.so -o libnspr4.so ./prvrsion.o io/./prfdcach.o io/./prmwait.o io/./prmapopt.o io/./priometh.o io/./pripv6.o io/./prlayer.o io/./prlog.o io/./prmmap.o io/./prpolevt.o io/./prprf.o io/./prscanf.o io/./prstdio.o threads/./prcmon.o threads/./prrwlock.o threads/./prtpd.o linking/./prlink.o malloc/./prmem.o md/./prosdep.o memory/./prshm.o memory/./prshma.o memory/./prseg.o misc/./pralarm.o misc/./pratom.o misc/./prcountr.o misc/./prdtoa.o misc/./prenv.o misc/./prerr.o misc/./prerror.o misc/./prerrortable.o misc/./prinit.o misc/./prinrval.o misc/./pripc.o misc/./prlog2.o misc/./prlong.o misc/./prnetdb.o misc/./prolock.o misc/./prrng.o misc/./prsystem.o misc/./prthinfo.o misc/./prtpool.o misc/./prtrace.o misc/./prtime.o malloc/./prmalloc.o pthreads/./ptsynch.o pthreads/./ptio.o pthreads/./ptthread.o pthreads/./ptmisc.o md/unix/./unix.o md/unix/./unix_errors.o md/unix/./uxproces.o md/unix/./uxrng.o md/unix/./uxshm.o md/unix/./uxwrap.o md/unix/./linux.o md/unix/./os_Linux_x86_64.o -lpthread -ldl /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld: io/./priometh.o: relocation R_X86_64_PC32 against `memcpy@@GLIBC_2.2.5' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value [...] david@Scott /usr/src/cvs/mozilla $ gcc --version gcc (GCC) 3.4.3-20050110 (Gentoo Hardened Linux 3.4.3.20050110-r1, ssp-3.4.3.20050110-0, pie-8.7.7)
*** Bug 86391 has been marked as a duplicate of this bug. ***
*** Bug 87448 has been marked as a duplicate of this bug. ***
i still run into bug 87448: /bin/sh ../libtool --silent --mode=link --tag=CXX x86_64-pc-linux-gnu-g++ -Wnon-virtual-dtor -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wconversion -Wchar-subscripts -Wall -W -Wpointer-arith -Wwrite-strings -g3 -fno-inline -g -ggdb -pipe -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -o libkdecore.la -rpath /usr/kde/3.4/lib -L/usr/qt/3/lib -R /usr/kde/3.4/lib -R /usr/kde/3.4/lib -R /usr/qt/3/lib -R /usr/lib64 -L/usr/lib64 -version-info 6:0:2 -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined libintl.lo kapplication.lo kdebug.lo netwm.lo kconfigbase.lo kconfig.lo ksimpleconfig.lo kconfigbackend.lo kmanagerselection.lo kdesktopfile.lo kstandarddirs.lo ksock.lo kpty.lo kprocess.lo kprocctrl.lo klocale.lo krfcdate.lo kiconeffect.lo kicontheme.lo kiconloader.lo kwin.lo kwinmodule.lo krootprop.lo kcharsets.lo kckey.lo kshortcut.lo kkeynative_x11.lo kkeyserver_x11.lo kaccelaction.lo kshortcutmenu.lo kaccelbase.lo kaccel.lo kglobalaccel_x11.lo kglobalaccel.lo kstdaccel.lo kshortcutlist.lo kcrash.lo kurl.lo kregexp.lo kglobal.lo kglobalsettings.lo kallocator.lo kvmallocator.lo kmimesourcefactory.lo kinstance.lo kpalette.lo kipc.lo klibloader.lo ktempfile.lo kuniqueapplication.lo kaccelmanager.lo ksavefile.lo krandomsequence.lo kstringhandler.lo kcompletion.lo kcmdlineargs.lo kaboutdata.lo kcompletionbase.lo knotifyclient.lo kaudioplayer.lo kdcoppropertyproxy.lo ksockaddr.lo kextsock.lo netsupp.lo kprocio.lo kbufferedio.lo kpixmapprovider.lo kurldrag.lo kmdcodec.lo ksocks.lo fakes.lo vsnprintf.lo ksycoca.lo ksycocadict.lo ksycocafactory.lo kxmessages.lo kstartupinfo.lo kcatalogue.lo kasyncio.lo kmultipledrag.lo kstaticdeleter.lo kappdcopiface.lo kclipboard.lo kcheckaccelerators.lo kdeversion.lo kdebugdcopiface.lo kcalendarsystem.lo kcalendarsystemgregorian.lo kcalendarsystemhijri.lo kcalendarsystemhebrew.lo kcalendarsystemfactory.lo kmacroexpander.lo kidna.lo ktempdir.lo kshell.lo kmountpoint.lo kcalendarsystemjalali.lo kprotocolinfo_kdecore.lo kprotocolinfofactory.lo kxerrorhandler.lo kuser.lo kconfigskeleton.lo kconfigdialogmanager.lo klockfile.lo ksycoca_skel.lo kappdcopiface_skel.lo kdebugdcopiface_skel.lo malloc/libklmalloc.la network/libkdecorenetwork.la svgicons/libkdesvgicons.la ../dcop/libDCOP.la ../libltdl/libltdlc.la -lXext -lresolv -lutil -L/usr/lib -lart_lgpl_2 -lm -lidn ../kdefx/libkdefx.la /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/kglobal.o: relocation R_X86_64_PC32 against `KGlobal::_locale' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.3-20050110/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[4]: *** [libkdecore.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/kdelibs-3.4.0/work/kdelibs-3.4.0/kdecore' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdelibs-3.4.0/work/kdelibs-3.4.0/kdecore' make[2]: *** [all] Error 2 make[2]: Leaving directory `/var/tmp/portage/kdelibs-3.4.0/work/kdelibs-3.4.0/kdecore' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdelibs-3.4.0/work/kdelibs-3.4.0' make: *** [all] Error 2 !!! ERROR: kde-base/kdelibs-3.4.0 failed. !!! Function kde_src_compile, Line 166, Exitcode 2 !!! died running emake, kde_src_compile:make Portage 2.0.51.19 (default-linux/amd64/2004.3, gcc-3.4.3-20050110, glibc-2.3.4.20050125-r1, 2.6.9-gentoo-r14 x86_64) ================================================================= System uname: 2.6.9-gentoo-r14 x86_64 AMD Opteron(tm) Processor 242 Gentoo Base System version 1.6.10 Python: dev-lang/python-2.3.5 [2.3.5 (#1, Feb 23 2005, 21:43:38)] dev-lang/python: 2.3.5 sys-devel/autoconf: 2.13, 2.59-r6 sys-devel/automake: 1.5, 1.8.5-r3, 1.7.9-r1, 1.6.3, 1.4_p6, 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="-g -ggdb -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/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-g -ggdb -pipe" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs autoconfig buildpkg ccache cvs debug distlocks multilib-strict sandbox" GENTOO_MIRRORS="http://distfiles.gentoo.org http://distro.ibiblio.org/pub/Linux/distributions/gentoo" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://buggy" USE="amd64 X acpi alsa berkdb bitmap-fonts cdr crypt curl debug dvd esd fam flac font-server fortran gdbm gif gnome gpm gstreamer gtk gtk2 imagemagick imlib ipv6 java jp2 jpeg lzw lzw-tiff mad motif mozilla mp3 mpeg mysql ncurses network nls nptl ogg oggvorbis opengl oss pam perl png python qt readline ruby sdl ssl svg tcltk tcpd tiff truetype truetype-fonts type1-fonts usb userlocales utf8 vorbis xml xml2 xpm xrandr xv zlib" Unset: ASFLAGS, CBUILD, CTARGET, LANG, LC_ALL, LDFLAGS, PORTDIR_OVERLAY
what version of gcc are you using
*** Bug 88892 has been marked as a duplicate of this bug. ***
*** Bug 89425 has been marked as a duplicate of this bug. ***
*** Bug 92460 has been marked as a duplicate of this bug. ***
*** Bug 93653 has been marked as a duplicate of this bug. ***
this is fixed
*** Bug 95218 has been marked as a duplicate of this bug. ***
*** Bug 102642 has been marked as a duplicate of this bug. ***
*** Bug 103915 has been marked as a duplicate of this bug. ***
I've seen this too, with gcc 4.0. I just assumed this was the fault of gcc 4, but now I see this is a general problem. Anyway, I've seen this with subversion too, for example (I don't currently remember the other one): cd subversion/bindings/java/javahl/native && /bin/sh /var/tmp/portage/subversion-1.2.3-r1/work/subversion-1.2.3/libtool --tag=CXX --silent --mode=link x86_64-pc-linux-gnu-g++ -O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1 -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -pthread -DNEON_ZLIB -DNEON_SSL -L/usr/lib64 -lstdc++ -rpath /usr/lib64 -o libsvnjavahl-1.la BlameCallback.lo CommitMessage.lo EnumMapper.lo Inputer.lo JNIByteArray.lo JNICriticalSection.lo JNIMutex.lo JNIStackElement.lo JNIStringHolder.lo JNIThreadData.lo JNIUtil.lo MessageReceiver.lo Notify.lo Notify2.lo Outputer.lo Path.lo Pool.lo Prompter.lo Revision.lo SVNAdmin.lo SVNBase.lo SVNClient.lo Targets.lo libsvnjavahl.la.lo org_tigris_subversion_javahl_SVNAdmin.lo org_tigris_subversion_javahl_SVNClient.lo ../../../../../subversion/libsvn_repos/libsvn_repos-1.la ../../../../../subversion/libsvn_client/libsvn_client-1.la ../../../../../subversion/libsvn_wc/libsvn_wc-1.la ../../../../../subversion/libsvn_ra/libsvn_ra-1.la ../../../../../subversion/libsvn_delta/libsvn_delta-1.la ../../../../../subversion/libsvn_subr/libsvn_subr-1.la /usr/lib64/libaprutil-0.la -lldap -llber -lgdbm -ldb-4.3 -lexpat /usr/lib64/libapr-0.la -lrt -lm -lcrypt -lnsl -lpthread -ldl -L/usr/lib64 -lneon -lz -lssl -lcrypto -ldl -L/usr/lib64 -Wl,-rpath -Wl,/usr/lib64 -O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1 -lgssapi_krb5 -lkrb5 -lk5crypto -lkrb5support -lcom_err -lresolv -lxml2 -lz -lm -lz /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2-beta20050908/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2-beta20050908/../../../../x86_64-pc-linux-gnu/bin/ld: .libs/Path.o: relocation R_X86_64_PC32 against `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string()@@GLIBCXX_3.4' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.2-beta20050908/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make: *** [subversion/bindings/java/javahl/native/libsvnjavahl-1.la] Fehler 1 !!! ERROR: dev-util/subversion-1.2.3-r1 failed. !!! Function src_compile, Line 128, Exitcode 2 Portage 2.0.52-r1 (default-linux/amd64/2005.1/no-symlinks, gcc-4.0.2-beta20050908-hardenednopie, glibc-2.3.5.20050725-r0, 2.6.12-rc1-cs2 x86_64) ================================================================= System uname: 2.6.12-rc1-cs2 x86_64 AMD Athlon(tm) 64 Processor 3000+ Gentoo Base System version 1.12.0_pre8 distcc 2.18.3 x86_64-pc-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] dev-lang/python: 2.4.1-r1 sys-apps/sandbox: 1.2.13 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.91.0.3 sys-devel/libtool: 1.5.20 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3/share/config /usr/lib/X11/xkb /usr/share/config /var/bind /var/qmail/alias /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe -D_FORTIFY_SOURCE=1 -fvisibility-inlines-hidden" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig distlocks multilib-strict sandbox sfperms strict" GENTOO_MIRRORS="http://gentoo.inode.at/ ftp://gentoo.inode.at/source/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo" LANG="de_DE@euro" LINGUAS="de en" MAKEOPTS="-j5" PKGDIR="/home/system/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="X aalib acl acpi alsa amd64 apache2 authdaemond avi berkdb bitmap-fonts bzip2 cairo caps cdb crypt curl devmap droproot eds emboss encode exif fam foomaticdb fortran gcj gd gdbm gif gmp gpm gs gstreamer gtk2 guile hardened iconv idn imagemagick imap imlib ipv6 java jpeg junit kerberos lcms ldap libg++ libgda libwww lzw lzw-tiff maildir mcal motif mp3 mpeg mysql ncurses nfsv4 nls nptl odbc oggvorbis opengl pam pdf pdflib perl php pic png postgres postscript python quicktime quotas readline samba sasl sdl slang snmp source spamassassin spell ssl tcl tcpd tiff truetype truetype-fonts type1-fonts unicode usb userlocales utf8 webdav xinerama xml xml2 xpm xv zlib linguas_de linguas_en userland_GNU kernel_linux elibc_glibc" Unset: ASFLAGS, CTARGET, LC_ALL, LDFLAGS
*** Bug 107193 has been marked as a duplicate of this bug. ***
I just filed bug 107193 which is a duplicate of this one (ksvg-3.5_beta1 and kgamma-3.5_beta1 were the packages that caused this error). Having read through this, I'm not certain what the actual status is since it's marked resolved but the error is still occurring.
I'm wondering as well. Is it possible to build kde with -fvisibility-inlines-hidden now? If, with which gcc version, 3.4 or 4.0? the upstream bug seems not to be fixed yet: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19664
never force visibility flags in your CFLAGS/CXXFLAGS if you do and things break, it's your fault
I don't talk about force, but kde claims to support it out of the box
Heinrich, KDE supports it with the following Qt patch applied: https://bugs.kde.org/show_bug.cgi?id=109386
is this stable? what about putting it in portage, at least as use flag or experimental or something like that?
Probably time to reopen, since the discussion is ging on... (In reply to comment #65) > is this stable? what about putting it in portage, at least as use flag or > experimental or something like that? I did not try. Personally I vote for applying the patch to Qt-3.3.5 and supporting it with KDE 3.5, but not 3.4.x, if we do not encounter a lot of other applications breaking due to -fvisibilty*.
I'm for NOT patching and NOT trying it at all. We already saw a lot of problems between KDE and Qt, with patches that were told to fix Qt problems. This is not the case, as I blogged, I had to disable the visibility stuff from 3.5 to have arts working. It tries to force an ABI setting in kde libraries and programs WITHOUT control over the ABI settings of the imported library. Every other C++ library would have the SAME exact problem as Qt.
I don't really know about the technical stuff here, but KDE claims to properly support it with 3.5. Still you have problems with arts, but did you use the qt patch, maybe it's even something that will be fixed if you report it.
See this bug: http://bugs.kde.org/show_bug.cgi?id=109386 I know for sure of arts/knotify because they are the only thing in my system that were built with visibility enabled (it was still disabled in kde-meta, but enable in kde eclass). Recompiled without visibility, arts, knotify and kmail doesn't crash anymore.
that might have been the problem, maybe something of the rest needed visibility as well for arts to work correctly
arts has NO dependency on the rest of kde, it would work WITHOUT anything else in kde... it was SEGFAULTING within STL code. It was NOT because visibility was missing it was because the visibility WAS PRESENT. They said 3.4 would have used it correctly, it didn't. They said 3.4.2 with the Qt patch would have used it correctly, it doesn't. They say 3.5 with another Qt patch will work, but I'm not sure if it's the case. As I said, Qt is NOT the ONLY C++ lib that is used by KDE, and basically NO lib are safe with -fvisibility=hidden enabled in user program.
(In reply to comment #67) > I'm for NOT patching and NOT trying it at all. As I said I didn't tried it yet and Qt 3.3.5 is hard masked, so it doesn't harm to test as you apparently did. I can live without the visibility support.
why is this re-opened ? if you want a bug to track KDE visibility stuff, file a new one the toolchain issues for which this bug exists are resolved
I opened bug 107193, now closed as a duplicate, but that was just for ksvg/kgamma. If someone who understands the broader issue of visibility much better than I do would open a new bug, I do still have questions regarding what workarounds are available.
(In reply to comment #73) > why is this re-opened ? Sorry, I assumed this bug would still be assigned to kde when reopening.
ok, but fact is that you didn't test arts with qt and the visibility patch
*** Bug 116873 has been marked as a duplicate of this bug. ***
*** Bug 118554 has been marked as a duplicate of this bug. ***
I'm having problems with this in kdegraphics. Nothing else on my system is having problems with this. My info is in Bug 118554.
@Michael: You could try applying this patch to your gcc: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00391.html But I can't promise it wont break anything. :)
*** Bug 122957 has been marked as a duplicate of this bug. ***
*** Bug 125048 has been marked as a duplicate of this bug. ***
*** Bug 125856 has been marked as a duplicate of this bug. ***
*** Bug 121134 has been marked as a duplicate of this bug. ***
*** Bug 128016 has been marked as a duplicate of this bug. ***
*** Bug 131247 has been marked as a duplicate of this bug. ***
