`-fvisibility-inlines-hidden` prevents kdevelop from linking succesfully. This should be filtered out. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Can you post the error that you get?
isn't that a gcc-3.5/4.0 option?
yes, but the gcc-3.4 ebuilds has already applied this patch.
Sorry, it's a c++ flag (CXXFLAGS) and I'm using gcc-3.4.2-r3 It has also been reported on the forum: http://forums.gentoo.org/viewtopic.php?t=239297 Compiling works but anything that links against it will fail. wxGTK suffers from the same flag but a bug about that has already been reported. This is the error message: make[4]: Entering directory `/var/tmp/portage/kdevelop-3.1.1/work/kdevelop-3.1.1/languages/ada' /bin/sh ../../libtool --silent --mode=link --tag=CXX i686-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 -O3 -march=athlon-mp -mtune=athlon-mp -pipe -ftracer -fvisibility-inlines-hidden -Wformat-security -Wmissing-format-attribute -fno-exceptions -fno-check-new -fno-common -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -fexceptions -Wl,-O1 -Wl,--enable-new-dtags -Wl,--sort-common -s -o libkdevadasupport.la -rpath /usr/lib/kde3 -lfl -L/usr/X11R6/lib -L/usr/qt/3/lib -L/usr/kde/3.3/lib -avoid-version -module -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -R /usr/kde/3.3/lib -R /usr/qt/3/lib -R /usr/X11R6/lib adasupportpart.lo problemreporter.lo backgroundparser.lo addclass.lo ada_utils.lo adasupport.lo AdaLexer.lo AdaParser.lo AdaTreeParserSuper.lo AdaStoreWalker.lo addclassdlg.lo configproblemreporter.lo ../../lib/libkdevelop.la ../../lib/antlr/src/libantlr.la /usr/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../i686-pc-linux-gnu/bin/ld: ../../lib/antlr/src/.libs/libantlr.a(TokenStreamSelector.o)(.text+0x2ee): unresolvable relocation against symbol `std::basic_string<char, std::char_traits<char>, std::allocator<char> >::~basic_string()@@GLIBCXX_3.4' /usr/lib/gcc/i686-pc-linux-gnu/3.4.2/../../../../i686-pc-linux-gnu/bin/ld: final link failed: Nonrepresentablesection on output collect2: ld returned 1 exit status make[4]: *** [libkdevadasupport.la] Error 1 make[4]: Leaving directory `/var/tmp/portage/kdevelop-3.1.1/work/kdevelop-3.1.1/languages/ada' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/var/tmp/portage/kdevelop-3.1.1/work/kdevelop-3.1.1/languages/ada' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/kdevelop-3.1.1/work/kdevelop-3.1.1/languages' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/kdevelop-3.1.1/work/kdevelop-3.1.1' make: *** [all] Error 2 Without -fvisibility-inlines-hidden it succeeds.
Any chance this flag will be filtered out? from http://bugs.gentoo.org/show_bug.cgi?id=68500 gcc 3.4.x in portage has the visibility patch and using -fvisibility-inlines-hidden in general should be safe, but not in the case of wxGTK 2.4.x (I haven't tested 2.5.x). It compiles but compiling anything against it won't work, ie aMule. same applies to kdevelop
Can anyone try the masked version of kdevelop? kde developers started supporting gcc visibility recently, if there's something not working it can be reported directly to them.
I am getting this with kdevelop-3.1.2 and gcc 3.4.3-r1
gcc version 3.4.3 20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) both 3.1.x and 3.2.x don't compile with CXXFLAGS="-fvisibility-inlines-hidden"
I can't understand a simple thing: Does it compile if you don't set CXXFLAGS="-fvisibility-inlines-hidden" ? If yes, then I think that this bug is "normal", many other packages will have problems with that forced options. This options shouldn't be added in the make.conf but it's upon of the package build system to enable it, like is done with the kde-3.4 sources like kdelibs, kdebase, kdepim and outher.
kde 3.1, what's that? ;)
This isn't... READ THIS: http://bugs.gentoo.org/show_bug.cgi?id=68500 And PLEASE patch the ebuild...
Created attachment 58237 [details] ebuild with filter flags This is how it should be using the 3.1.2 ebuild. But this applies to all versions in portage 7 months...
So basically, the reason for not changing the ebuild is that: - People shouldn't use such a flag, or ANYTHING except for -Ox -march/mtune -pipe -fomit-frame-pointer (and maybe some other exotic arch-specific things), in global make.conf CFLAGS. Those who do usually get their bugs marked invalid. - If we started changing ebuilds as requested ebuild, we'd have to change a _lot_ of them for every flag like this one. This particular flag also falls under the 'don't use' clause because it changes the behavior of the compiled binary (unlike optimizations which achieve the same end in faster/smaller ways). Therefore only the packages themselves should ever turn it on. I don't know how many packages rely on inline function symbols being externally visible by default, but it's a valid feature, I think. Or does some standard somewhere tell us not to rely on it? (In which case, the kdevelop code would have to be fixed, not the ebuild) I don't fully grok the error message in this particular case though. I don't have a deep understanding of c++ linking magic. For all I know there's a real bug here... If there's no extra bug here, I think this should be closed.
This is a list of ebuilds that filter -fvisibility-inlines-hidden. /usr/portage/app-i18n/scim/scim-1.2.1.ebuild /usr/portage/app-i18n/scim/scim-1.2.2.ebuild /usr/portage/dev-libs/libffi/libffi-3.3.5.ebuild /usr/portage/dev-libs/libffi/libffi-3.4.1.ebuild /usr/portage/dev-libs/libffi/libffi-3.4.1-r1.ebuild /usr/portage/dev-libs/libffi/libffi-3.4.3.ebuild /usr/portage/sys-libs/libstdc++-v3/libstdc++-v3-3.3.3-r1.ebuild /usr/portage/sys-libs/libstdc++-v3/libstdc++-v3-3.3.4.ebuild /usr/portage/x11-libs/wxGTK/wxGTK-2.4.2-r2.ebuild /usr/portage/x11-libs/wxGTK/wxGTK-2.4.2-r3.ebuild Either tell them to remove the filter or add it to kdevelop.
Just because a few other ebuilds filter this flag is not justification for applying filtering here too. The flag you are using globally is code specific - that point is valid, and it should only be turned on by the build system of packages that want to use this functionality. Applying this flag globally is simply not supported, and so does not need filtering. I hope you can see the reasons why, but I don't think we should start filtering on every possible flag that can break code. Stuff like this should not be applied globally. Closing this bug, I agree with danarmak on this issue.
