This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
Failing code: template<typename CharT> struct VisTest { inline VisTest (); }; template<typename CharT> inline VisTest<CharT>::VisTest() {} extern template class VisTest<char>; // It works if we drop that line int some_function( int do_something ) __attribute__ ((visibility("default"))); int some_function( int do_something ) { VisTest<char> a; return 0; } g++ -fPIC -fvisibility=hidden -fvisibility-inlines-hidden lib.cpp -c g++ -shared -fPIC -fvisibility=hidden -fvisibility-inlines-hidden lib.o -o liblib.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld: lib.o: relocation R_X86_64_PC32 against `VisTest<char>::VisTest()' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.0.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status This happens with nearly all cases in which libstdc++ headers are involved: http://bugs.gentoo.org/show_bug.cgi?id=78720 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
Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug: http://bugs.gentoo.org/show_bug.cgi?id=79711 ???
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.
I think HJ may be interested...
>Thanks for the nice testcase. Is this really a GCC bug, or a binutils bug: > >http://bugs.gentoo.org/show_bug.cgi?id=79711 Downgrading binutils from 2.15.92.0.2 to 2.15.90.0.1.1 fixed the compilation for all KDE packages except kdepim. But kdepim failed with another probably not related error.
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.
(In reply to comment #5) > 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.
If it is a programmers bug, why does it happen only with amd64, but not with ia32 or ia64? > 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. This does not explain why gcc should fail to create the library. In my opinion the programmer isnt the one to blame, he declared a strucutre, which should not be exported to the library, and a function that should be exported. Within his library he uses that structure, whats wrong about that?
I am also refereing to this example: http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html
(In reply to comment #8) > I am also refereing to this example: > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html Now there is a libstdc++ bug for not using pop/push of the visibility in the headers which is not what I orginally thought this bug was about.
(In reply to comment #9) > (In reply to comment #8) > > I am also refereing to this example: > > http://gcc.gnu.org/ml/libstdc++/2005-01/msg00300.html > > Now there is a libstdc++ bug for not using pop/push of the visibility in the headers which is not what > I orginally thought this bug was about. If you actually commented saying that this came from libstdc++ and then I would have commented saying that there needs some push/pop in the headers but instead you gave a simplified example which is not a gcc/linker bug but a programmers mistake. Confirmed, changing the summary to match the correct the sumbitter's mistake of not giving the full story.
Note the orginal testcase is: #include <string> int some_function( std::string const& do_something ) __attribute__ ((visibility("default"))); int some_function( std::string const& do_something ) { std::string another_string; return 0; }
I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase.
(In reply to comment #12) > I am sorry, in my attempt to reduce the exmaple I introduced a bug in the testcase. Yes and this is not a target related bug at all but a libstdc++ one.
Interesting ;) After so many months, it turns out we have to add push/pop to *all* the headers?!? Why nobody mentioned that before?!? Not a big deal, in case, but I'm somewhat suprised.
Ok, now I see the issue clearly: http://gcc.gnu.org/ml/gcc-patches/2004-08/msg00114.html In particular: "I did not attempt to fix all of the V3 headers; I'm only concerned with libsupc++ at the moment. However, similar changes should probably be made throughout V3. Otherwise, linkage will be wrong if people #include (say) <iostream> with a non-default symbol visibility." Will fix this.
Adding pragma visibility push(default)/pop to the basic_string.h header (or to the std_string.h header, for that matter) does *not* fix the issue for me. Is anyone able to confirm this or viceversa? (binutils 2.15.91.0.2 on x86_64)
By the way: if this is really a generic problem in libstdc++, why I cannot reproduce it on x86? There, I'm using mainline as of February, 1 + binutils 2.15.94.0.2.
Hummm: http://sources.redhat.com/ml/binutils/2005-01/msg00511.html
My linker patch is for PROTECTED function symbols. It tries to prevent http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit while the address space is 64bit. x86 doesn't have this issue.
> My linker patch is for PROTECTED function symbols. It tries to prevent > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19520 Ok, just checked the testcase in binutils/584. > BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit > while the address space is 64bit. x86 doesn't have this issue. OK, noted. Now, why: 1- Adding visibility push(default)/pop to the library does *not* help on x86_64 for this (comment #11) testcase? 2- Why visibility push(default)/pop are necessary only on x86_64?!? Sorry, two naive questions, but really before delving in the technical details I want to be sure that overall things are consistent.
In other terms, I understand this > BTW, R_X86_64_PC32 CAN NOT be used for global symbols since it is only 32bit > while the address space is 64bit. x86 doesn't have this issue. as meaning that the compiler should *not* emit R_X86_64_PC32 in the first place, irrespective od other "details" affecting the c++ library. Thus, a *compiler* bug, certainly.
I believe it is a real compiler bug. I will see what I can do.
I am not sure if visibility push(default)/pop works at all since handle_pragma_visibility, which sets `default_visibility' with visibility push(default)/pop, is called AFTER build_decl_stat is called which uses default_visibility to set visibility.
Thanks HJ, things are becoming more and more ""interesting""... :-/ Seriously, I think we should split the issues: separate PRs, one category -target- for the relocation, one -library- for the missing visibility push(default)/pop. Maybe even a third one, -c++-, for the issue that you are reporting now. Help welcome...
I think the C++ compiler simply ignores default_visibility. That may be why push(default)/pop doesn't work.
I see, but please compare to the link in Comment #15: Mark Mitchell added visibility push(default)/pop to libsupc++ sure that the pragma was ok :-(
It is not OK. determine_visibility in C++ is called after ALL visibility push(default)/pop are processed. It has else if (TREE_CODE (decl) == FUNCTION_DECL && DECL_DECLARED_INLINE_P (decl) && visibility_options.inlines_hidden) { DECL_VISIBILITY (decl) = VISIBILITY_HIDDEN; DECL_VISIBILITY_SPECIFIED (decl) = 1; } Here is where the problem comes from.
So this is both a compiler bug and a v3 bug. HJL provided a patch for the C++ frontend here: http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html Notice that the patch is incomplete because it is missing a testcase.
A testcase suitably distilled from #11 should do. For the libstdc++ side of the problem, we are missing a testcase. Probably, it's better opening a separate, complete libstdc++ PR: then fixing the latter will be straightforward (just add push/pop everywhere, I have a draft ready).
But, on second thought, sorry, I think we have also a third problem, target dependent, for R_X86_64_PC32 relocaltions wrongly emitted for global symbols on x86_64.
Actually, the testcase in comment #11 is about the *third* issue, AFAICS.
I don't think emitting R_X86_64_PC32 is a bug since -fvisibility=hidden -fvisibility-inlines-hidden is used and the undefined function can be defined in another .o file. The real bug is gcc doesn't emit .hidden foo when foo is marked hidden and undefined.
The testcase patch is at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html To properly support -fvisibility-inlines-hidden, ASM_OUTPUT_EXTERNAL should be defined. We can collected undefined symbols with non-default visibility and generate the assmebly directives in TARGET_ASM_FILE_END.
Personally, I think the better approach for the libstdc++ parts is to allow __attribute__ visibility on namespace declarations. That way, all this goo could be removed, and centralized in one place. Ie, c++config.h could have something like: namespace std __attribute__ ((visibility ("default") )); { } And volia! We are done. (When I first saw this, I thought that the solution being proposed was mass decoration of std:: names with some kind of pseudo-__declspec bullshit. Of course, that is a non-starter, so I'm glad to see the thinking has evolved a bit.) -benjamin
HJL: would you please open a different bug report for the x86-64 issue and link it to this bug? Benjamin: can you open a different enhancement proposal about supporting the visibility attribute at namespace-level? Anyway, I think the correct way to go for 4.0 is to use the pragmas. A patch against the 4.0 branch would be much appreciated.
There are 3 bugs here: 1. libstdc++ should have pop/push of the visibility. 2. C++ should support pop/push of the visibility. 3. Gcc should emit ".hidden foo" when foo is marked hidden, defined or not. Patches for #2 are at http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00287.html I opened a bug for #3, bug 20218.
So, any progress on this whole issue? I don't see either the pragmas in the C++ headers, nor HJs changes to the c++ frontend (despite testcase) in CVS. Just for the record, I see these problems (linkproblem with test from comment #11) also on ppc and ppc64, so it's not just a target dependend problem. On ppc64 it's an unresolvable R_PPC64_REL24 relocation, and on ppc it's simply an undefined reference to the std::string ctor.
Oh, and just annotating the testcase with the visibility push/pop #pragma is not enough, probably because of the problem in the c++ frontend, HJ noted.
Hi Michael and thanks for asking: really, I'm lost in this tangle of front-end, back-end and library issues. When I'm back from Oxford really want to move the issue forward, somehow, asking all the knowledgeable people (besides doing myself the, rather trivial, it seems, library bits). In the meanwhile, if you are able to see clearly which front-end/back-end patches among all those proposed here and posted on gcc-patches are *definitely* improvements, please patronize and ping on gcc-patches...
*** Bug 21382 has been marked as a duplicate of this bug. ***
Created an attachment (id=8908) [edit] Old libstdc++ patch, probably correct besides copyrights
Created an attachment (id=8909) [edit] reworked patch_19664. it applies on gcc_4 branch now.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations pluto at agmk dot net wrote: > ------- Additional Comments From pluto at agmk dot net 2005-05-17 09:41 ------- > Created an attachment (id=8909) [edit] > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8909&action=view) > reworked patch_19664. it applies on gcc_4 branch now. This patch looks sensible to me, but it should be approved by a V3 maintainer.
> This patch looks sensible to me, but it should be approved by a V3 > maintainer. Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't have those bits already is that there are outstanding front-end issues that apparently nobody cares about. Can you possible have a look to my last summary of the situation: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg00275.html ??? Notice that in the meanwhile HJ posted/attached an updated patch for 20218. Do we at least agree that these are real bugs? Who is in charge of maintaining this visibility stuff? I'm finding the situation wrt to those visibility issues a little puzzling: apparently is a nice feature that we all want, but, on the other hand, nobody pays attention to those long-standing bug reports. Sorry about the rant ;)
(In reply to comment #44) I've tested PR19664 patch + updated PR20218 patch + v3 patch and they work fine on amd64. I'll test fixes soon on powerpc on testcase from PR21382 too.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations pcarlini at suse dot de wrote: > ------- Additional Comments From pcarlini at suse dot de 2005-05-17 19:05 ------- > >>This patch looks sensible to me, but it should be approved by a V3 >>maintainer. > > > Thanks a lot Mark, I'll try to get to it soon. But, the real reason we don't > have those bits already is that there are outstanding front-end issues that > apparently nobody cares about. One of HJ's patches is a middle-end patch, and I'm not sure I know enough to review it. I'd have to start by researching the ELF spec, for example, and we've found that various version of binutils have weird behavior around weak/linkonce. So, I'm scared of that one. The front end patch is OK.
Subject: Bug 19664 CVSROOT: /cvs/gcc Module name: gcc Changes by: hjl@gcc.gnu.org 2005-05-17 21:47:13 Modified files: gcc/cp : ChangeLog decl2.c Log message: 2005-05-17 H.J. Lu <hongjiu.lu@intel.com> PR C++/19664 * decl2.c (determine_visibility): Don't set visibility to hidden if it has been set explicitly by user. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4745&r2=1.4746 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl2.c.diff?cvsroot=gcc&r1=1.781&r2=1.782
Mark, is http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html OK for mainline as well as 4.0?
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations hjl at lucon dot org wrote: > ------- Additional Comments From hjl at lucon dot org 2005-05-17 21:50 ------- > Mark, is > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html > > OK for mainline as well as 4.0? It's OK for mainline. It's not OK for 4.0 unless it's a regression.
> One of HJ's patches is a middle-end patch, and I'm not sure I know > enough to review it. I'd have to start by researching the ELF spec, for > example, and we've found that various version of binutils have weird > behavior around weak/linkonce. So, I'm scared of that one. I understand, of course. Maybe, with your release manager and global maintainer hat, you can "officially" ask the intervention of a middle-end person? My point was also this one... > The front end patch is OK. Thanks a lot. And, as soon as "pluto" has finished testing the whole package I will personally take care of the v3 bits.
(In reply to comment #50) > Thanks a lot. And, as soon as "pluto" has finished testing the whole package > I will personally take care of the v3 bits. on powerpc OpenEXR builds/links fine too. finally it works on amd64/powerpc/ia32 with -fvisibility-inlines-hidden. these 3 patches stay with me :)
Great! I forgot to thank you for all your testing efforts: thanks! I'm going to have a final look and commit the v3 bits. Then, strong of your test, I'm also going to ping again on gcc-patches the middle-end bits.
(In reply to comment #49) > > Mark, is > > > > http://gcc.gnu.org/ml/gcc-patches/2005-02/msg00180.html > > > > OK for mainline as well as 4.0? > > It's OK for mainline. It's not OK for 4.0 unless it's a regression. It's not a regresion, but it causes KDE to miscompile with GCC 4.0.0. Could we apply it for 4.0 anyway?
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations bernie at develer dot com wrote: > It's not a regresion, but it causes KDE to miscompile > with GCC 4.0.0. Could we apply it for 4.0 anyway? No; we confine ourselves to regressions. If it wasn't a regression, there must be some workaround that KDE is using for previous releases that it can continue to use here.
no workaround, the flag was just disabled on the affected architectures
(In reply to comment #54) > Subject: Re: libstdc++ headers should have pop/push > of the visibility around the declarations > > bernie at develer dot com wrote: > > > It's not a regresion, but it causes KDE to miscompile > > with GCC 4.0.0. Could we apply it for 4.0 anyway? > > No; we confine ourselves to regressions. If it wasn't a regression, > there must be some workaround that KDE is using for previous releases > that it can continue to use here. kde-core team already blacklisted gcc-4.0.0 due to detected bugs. they'll probably do the same thing with incoming 4.0.x releases due to gcc's rules which block major bugfixes != regression fixes. there is no logic reason for making workarounds for valid c++ code and releasing buggy 4.0.x branch.
(In reply to comment #52) > Great! I forgot to thank you for all your testing efforts: thanks! (...) i'll test these fixes on alpha/sparc{32,64} too in near feature. i have machines but no time :/
FWIW, I agree, as far as the visibility issues are concerned (I don't want to say something more general): the issues are *long* standing, important projects are already using the features and nobody (almost ;) cares about the bugs in the existing implementation. This is BAD. Either we fix those bugs ASAP, everywhere the feature is present, or (we scrap away everything and/or advertise the feature itself as broken).
Created an attachment (id=8934) [edit] Very slightly improved mainline patch for libstdc++-v3 Includes for completeness two missing TR1 headers; adjusts a DejeGNU line number mismatch in the auto_ptr/assign_neg.cc test.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations lanius at gentoo dot org wrote: > ------- Additional Comments From lanius at gentoo dot org 2005-05-20 08:35 ------- > no workaround, the flag was just disabled on the affected architectures Then, can it not be left disabled for 4.0.x as well?
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations "mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes: > Then, can it not be left disabled for 4.0.x as well? It could - but people do want to use it. This is a rather important improvement and people have been waiting for this feature to see it in production since some time now. Andreas
(In reply to comment #59) > Created an attachment (id=8934) [edit] > Very slightly improved mainline patch for libstdc++-v3 gcc-4.1-20050701T1908UTC with patches: { ada-fwrapv pr7776 pr20218 pr20297 push-pop-visibility pr21704 pr22051 pr22071 pr17640 pr22037 pr22037 pr19055 } binutils-2.16.91.0.1 on ia32 bootstrap (with all langs) works fine. on amd64 libstdc++ fails: (...) -march=x86-64 -O2 -fvisibility-inlines-hidden -D_GNU_SOURCE -fno-implicit-templates -Wall -W extra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c c++locale.cc -fPIC -DPIC -o .libs/c++locale.o /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc -shared-libgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/ -nostdinc++ -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs -B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem /usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include -I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/include/x86_64-pld-linux -I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/include -I/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/libstdc++-v3/libsupc++ -march=x86-64 -O2 -fvisibility-inlines-hidden -D_GNU_SOURCE -fno-implicit-templates -Wall -W extra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -c c++locale.cc -o c++locale.o >/dev/null 2>&1 cp /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/libstdc++-v3/config/linker-map.gnu ./libstdc++-symbol.ver if test "x" != x; then \ sed -n '1,/DO NOT DELETE/p' libstdc++-symbol.ver > tmp.top; \ sed -n '/DO NOT DELETE/,$p' libstdc++-symbol.ver > tmp.bottom; \ cat tmp.top tmp.bottom > libstdc++-symbol.ver; \ rm tmp.top tmp.bottom; \ fi /bin/sh ../libtool --tag CXX --mode=link /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc -shared-libgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/ -nostdinc++ -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs -B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem /usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include -Wl,-O1 -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o libstdc++.la -rpath /usr/lib64/../lib64 -version-info 6:6:0 -Wl,--version-script=libstdc++-symbol.ver -lm bitmap_allocator.lo pool_allocator.lo mt_allocator.lo codecvt.lo compatibility.lo complex_io.lo ctype.lo debug.lo debug_l ist.lo functexcept.lo globals_locale.lo globals_io.lo ios.lo ios_failure.lo ios_init.lo ios_locale.lo limits.lo list.lo locale.lo locale_init.lo locale_facets.lo localename.lo stdexcept.lo strstream.lo tree.lo allocator-inst.lo concept-inst.lo fstream-inst.lo ext-inst.lo io-inst.lo istream-inst.lo istream.lo locale-inst.lo locale-misc-inst.lo misc-inst.lo ostream-inst.lo sstream-inst.lo streambuf-inst.lo streambuf.lo string-inst.lo valarray-inst.lo wlocale-inst.lo wstring-inst.lo atomicity.lo codecvt_members.lo collate_members.lo ctype_members.lo messages_members.lo monetary_members.lo numeric_members.lo time_members.lo basic_file.lo c++locale.lo ../libmath/libmath.la ../libsupc++/libsupc++convenience.la -lm /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/xgcc -shared-libgcc -B/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/ -nostdinc++ -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs -B/usr/x86_64-pld-linux/bin/ -B/usr/x86_64-pld-linux/lib/ -isystem /usr/x86_64-pld-linux/include -isystem /usr/x86_64-pld-linux/sys-include -shared -nostdlib /usr/lib64/gcc/x86_64-pld-linux/../../../lib64/crti.o /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/crtbeginS.o .libs/bitmap_allocator.o .libs/pool_allocator.o .libs/mt_allocator.o .libs/codecvt.o .libs/compatibility.o .libs/complex_io.o .libs/ctype.o .libs/debug.o .libs/debug_list.o .libs/functexcept.o .libs/globals_locale.o .libs/globals_io.o .libs/ios.o .libs/i os_failure.o .libs/ios_init.o .libs/ios_locale.o .libs/limits.o .libs/list.o .libs/locale.o .libs/locale_init.o .libs/locale_facets.o .libs/localename.o .libs/stdexcept.o .libs/strstream.o .libs/tree.o .libs/allocator-inst.o .libs/concept-inst.o .libs/fstream-inst.o .libs/ext-inst.o .libs/io-inst.o .libs/istream-inst.o .libs/istream.o .libs/locale-inst.o .libs/locale-misc-inst.o .libs/misc-inst.o .libs/ostream-inst.o .libs/sstream-inst.o .libs/streambuf-inst.o .libs/streambuf.o .libs/string-inst.o .libs/valarray-inst.o .libs/wlocale-inst.o .libs/wstring-inst.o .libs/atomicity.o .libs/codecvt_members.o .libs/collate_members.o .libs/ctype_members.o .libs/messages_members.o .libs/monetary_members.o .libs/numeric_members.o .libs/time_members.o .libs/basic_file.o .libs/c++locale.o -Wl,--whole-archive ../libmath/.libs/libmath.a ../libsupc++/.libs/libsupc++convenience.a -Wl,--no-whole-archive -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld- linux/libstdc++-v3/src -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/x86_64-pld-linux/libstdc++-v3/src/.libs -lm ../libmath/.libs/libmath.a -lm ../libsupc++/.libs/libsupc++convenience.a -lm -L/home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc -L/usr/lib64/gcc/x86_64-pld-linux/../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -lgcc_s -lc -lgcc_s -lm -lgcc_s -lc -lgcc_s /home/users/builder/rpm/BUILD/gcc-4.1-20050701T1908UTC/obj-x86_64-pld-linux/./gcc/crtendS.o /usr/lib64/gcc/x86_64-pld-linux/../../../lib64/crtn.o -Wl,-O1 -Wl,--version-script=libstdc++-symbol.ver -Wl,-soname -Wl,libstdc++.so.6 -o .libs/libstdc++.so.6.0.6 /usr/bin/ld: .libs/string-inst.o: relocation R_X86_64_PC32 against `_ZNSt11char_traitsIcE2eqERKcS2_@@GLIBCXX_3.4.5' can not be used when making a shared object; recompile with -fPIC /usr/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[4]: *** [libstdc++.la] Error 1 should i update the mainline patch?
> should i update the mainline patch? Well, thanks for the offer, but the real blocker is 20218, which cannot be fixed yet, because, basically, *all* the back ends need tweaking: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg02226.html Probably, I should find a way to more effectively ping the maintainers...
*** Bug 22482 has been marked as a duplicate of this bug. ***
*** Bug 22587 has been marked as a duplicate of this bug. ***
*** Bug 22185 has been marked as a duplicate of this bug. ***
*** Bug 23628 has been marked as a duplicate of this bug. ***
There was a comment in here about making visibility control happen at the namespace level. How would this work with, say, 'vector<mytype>'? I would expect that if -fvisibility=hidden is set, then this instantiation should also be hidden, because presumably 'mytype' is a type private to this object. If some other object defines a different 'mytype', it certainly shouldn't use the same 'vector' implementation.
*** Bug 24272 has been marked as a duplicate of this bug. ***
whats the status of the patch? can we at least have the visibility push/pop patch for libstdc++ in gcc 4.0.x branch? Marc: what is the reason this patch is rejected? sure its not a regression, but visibility support is entirely useless without visibility support in libstdc++. The push/pop part is not the ideal solution (as it basically disables visibility for libstdc++), but its a can't-break workaround for a very pressing bug.
(In reply to comment #70) > whats the status of the patch? can we at least have the visibility push/pop > patch for libstdc++ in gcc 4.0.x branch? See comment #63: at this stage changing libstdc++ is pointless.
why is it pointless? just because it doesn't work on some target architectures doesn't mean it doesn't work on most main archs. I find it pointless that a patch isn't applied just because it doesn't work on some archs (while it doesn't additionally break anything on those archs because all *this* patch does is to *ensure* that hidden visibility is disabled)
(In reply to comment #72) > why is it pointless? just because it doesn't work on some target architectures > doesn't mean it doesn't work on most main archs. Are you really, really, sure that without patching the middle-end at all, only changing the libstdc++-v3 headers benefits some targets without any side effects? I'm not at all, given this tangle. Really, we want someone to work seriously on the various serious outstanding bugs of the machinery, please if you consider it useful in principle for your project ask the maintainers and the knowledgeable compiler people to work on it, I tried, but I failed, by and large.
yes, well one reason for it is that several libs (e.g. libgcc2) already use push/pop visibility macros and it doesn't seem to harm. furthermore I manually added push/pop macros to libstdc++ headers on a debian system (which is broken regarding visibility support) and it made my testcase pass.
(In reply to comment #74) > furthermore I manually added push/pop macros to libstdc++ headers on a debian > system (which is broken regarding visibility support) and it made my testcase > pass. To be clear: I have nothing against adding those push/pop missing the middle-end fixes. But I want to be 100% sure that nothing breaks. Thus my plan: I will update the patch doing that for mainline and ask Roger (the most qualified person, apparently) before committing.
Created an attachment (id=10085) [edit] hidden visibility for __gnu_internal Without per-namespace visibility attributes, this is what we will have to do for the known internal parts of libstdc++.
Thanks Benjamin! Indeed, if you want to take care of this entire issue, you are welcome (just reassign)! In any case, I'm not sure whether it's suited for 4.1, at this point...
Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? Waiting for 4.2 means that unpatched gcc's will suffer for more.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 10:37 AM, ismail at uludag dot org dot tr wrote: > ------- Comment #78 from ismail at uludag dot org dot tr > 2005-10-31 18:37 ------- > Paolo, this is surely a bug fix. Why can't it make it to 4.1 ? > Waiting for 4.2 > means that unpatched gcc's will suffer for more. > I don't think the problem is solved yet, is it? In addition to the question of whether the patch is actually safe for all architectures, there's also still the question of using standard library templates, like 'vector', on hidden types; this works now if you use - fvisibility=hidden, and it'd stop working if the patch was applied, so you'd just be trading one problem for another. Better I think to not make this change in 4.1, at least that can't introduce any regressions, and work on the problem for 4.2. However, maybe the problem would be much reduced if we marked some specific classes as not hidden: those which are thrown as exceptions. There are only a handful of them, so we could do that with just an attribute, and surely that would be safe. What do people think of that?
- if its not safe for all architectures we'd already run into heaps of problems because both libsupc++ and libgcc2 already include similiar pragmas. - not hiding a symbols is better than the resulting issues when hiding a symbol which should be exported. for example right now the function static pointer pointing to libstdc++'s memory allocator is hidden, which causes STL usages to just randomly crash when used across linking boundaries. crashing is worse than the performance penality by exported symbols - of course just exporting those classes that *should* be exported would be much more clever. I just thought if its so difficult to get a brain-dead simple patch that makes everything work not getting applied within 6 months then the stripped-down just-exporting-what-is-really needed (which requires a lot of in-depth knowledge and a lot of testing) would need more something like 6 years to get applied. Anyway, I volunteer to help reducing the amount of exported classes if thats what makes you apply the patch. The current brute-force export-all patch fixes everything and is dead simple compared to such a "only export what is needed patch".
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 2:45 PM, mueller at kde dot org wrote: > ------- Comment #80 from mueller at kde dot org 2005-10-31 22:45 > ------- > - not hiding a symbols is better than the resulting issues when > hiding a symbol > which should be exported. for example right now the function > static pointer > pointing to libstdc++'s memory allocator is hidden, which causes > STL usages > to just randomly crash when used across linking boundaries. > crashing is worse > than the performance penality by exported symbols > I wasn't thinking so much of the performance penalty, but rather of the ABI impact. Suddenly, your dynamic library, which you thought had carefully controlled exports (maybe it shouldn't export any C++ interfaces of its own at all), is exporting a global C++ type, 'std::vector<mytype>', which could conflict with any similarly-named- but-different type anywhere in a program that uses the library. Performance is also a concern, of course. > - of course just exporting those classes that *should* be exported > would be > much more clever. I just thought if its so difficult to get a > brain-dead > simple patch that makes everything work not getting applied within > 6 months > then the stripped-down just-exporting-what-is-really needed (which > requires > a lot of in-depth knowledge and a lot of testing) would need more > something > like 6 years to get applied. > > Anyway, I volunteer to help reducing the amount of exported classes > if thats > what makes you apply the patch. The current brute-force export-all > patch > fixes everything and is dead simple compared to such a "only export > what > is needed patch". > Well (after re-reading what the bug was originally about): - You'll notice that the bug is about things which are not defined in this library, which can't possibly include the things I'm concerned about above, since every part of std::vector<mytype> must be defined in this library since nothing else knows about 'mytype'. So it's certainly possible to fix it. - But, I'm not sure that the front-end supports everything you'll need to mark all the right pieces. For instance, ctype<mytype> has to be hidden, but ctype<char> has to be not hidden. It would probably be easier to teach the front-end that "if I'm instantiating something, the resulting thing must have the most restrictive visibility of any of its parameters" than it would be to go around trying to put attributes on each little method. - If that's too hard to do in time for 4.1, we could at least fix the related problems for non-x86-64 systems, which have to do with the classes thrown as exceptions; it's not useful to compile them with hidden visibility, since they're passed between libraries. (They're mostly in libsupc++.)
To clarify: I have unassigned myself from this bug because I don't consider myself sufficiently competent in this area to evaluate all the possible trade- offs of the issue and don't want to block in any way the work of knowledgeable people, Geoff, for instance. Help is much appreciated. Thanks.
I agree Geoff, we should hold off on this for 4.1, and try to hit 4.2. If things get solid sooner, maybe this can be reconsidered. Adding this patch to 4.0.x is out of the question, it has the potential to change too many things. I am working on this general issue at the moment. So, I will reassign to me since Paolo suggested it. Geoff, it's not as simple as just marking throwable types, all typeinfo, etc. I'm performing an audit, but it's stuff like local statics as well. This has to be done very carefully for a C++ library, which isn't as clearly defined as C libraries that are already using this feature (but that don't have to deal with vague linkage.) I'll come up with a gcc bugzilla enhancement request for visibility attributes on namespaces this week.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 31/10/2005, at 7:59 PM, bkoz at gcc dot gnu dot org wrote: > Geoff, it's not as simple as just marking throwable types, all > typeinfo, etc. > I'm performing an audit, but it's stuff like local statics as well. > Right, I wasn't trying to say that just marking the throwable types would be a complete solution (for anyone), just that it was easy, clearly correct as far as it went, and it would reduce the problem. > This has to be done very carefully for a C++ library, which isn't > as clearly defined as C libraries that are already using this > feature (but that don't have to deal with vague linkage.) > Plus, we don't really know what it should mean yet. For instance, if everything is compiled with visibility hidden, and dylib A throws "vector<int>", should that be catchable in dylib B? I can think of good arguments for "yes", "no", and "undefined", which I guess means that "undefined" should win.
Created an attachment (id=10094) [edit]
Created an attachment (id=10120) [edit] Updated version of the patch to apply on current SVN
current 4.1(+libstdc++ patch) works fine for PR21382 on amd64 and ppc.
This patch doesn't solve the vector<mytype> issue, does it? It doesn't look like it, I would have expected it to need some C++ frontend changes.
*** Bug 26217 has been marked as a duplicate of this bug. ***
with 4.1.1 snapshot + patches I get an arts crash today on my x86_64 box. Starting program: /usr/bin/artsd Program received signal SIGSEGV, Segmentation fault. 0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate () from /usr/lib64/libartsflow.so.1 (gdb) bt #0 0x00002aaaaaf641d8 in __gnu_cxx::__mt_alloc<Arts::Notification*, __gnu_cxx::__common_pool_policy<__gnu_cxx::__pool, true> >::allocate () from /usr/lib64/libartsflow.so.1 #1 0x00002aaaaba4a908 in std::_Deque_base<Arts::Notification, std::allocator<Arts::Notification> >::_M_initialize_map () from /usr/lib64/libmcop.so.1 #2 0x00002aaaaba49145 in Arts::NotificationManager::NotificationManager () from /usr/lib64/libmcop.so.1 #3 0x00002aaaaba2660a in Arts::Dispatcher::Dispatcher () from /usr/lib64/libmcop.so.1 #4 0x000000000041c227 in main (argc=1, argv=0x7fffffe818f8) at artsd.cc:275 arts works fine with visibiliy feature disabled. $ gcc -v Reading specs from /usr/lib64/gcc/x86_64-pld-linux/4.1.1/specs Target: x86_64-pld-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --libdir=/usr/lib64 --libexecdir=/usr/lib64 --infodir=/usr/share/info --mandir=/usr/share/man --x-libraries=/usr/lib64 --enable-shared --enable-threads=posix --enable-languages=c,c++,fortran,objc,obj-c++,ada,java --enable-c99 --enable-long-long --enable-multilib --enable-nls --disable-werror --with-gnu-as --with-gnu-ld --with-demangler-in-ld --with-system-zlib --with-slibdir=/lib64 --without-system-libunwind --enable-cmath --with-long-double-128 --with-gxx-include-dir=/usr/include/c++/4.1.1 --disable-libstdcxx-pch --enable-__cxa_atexit --enable-libstdcxx-allocator=mt --with-qt4dir=/usr/lib64/qt4 --disable-libjava-multilib --enable-libgcj --enable-libgcj-multifile --enable-libgcj-database --enable-gtk-cairo --enable-java-awt=qt,gtk,xlib --enable-jni --enable-xmlj --enable-alsa --enable-dssi x86_64-pld-linux Thread model: posix gcc version 4.1.1 20060308 (prerelease) (PLD-Linux)
well, of course, because your libstdc++ is compiled with the wrong (LSB incompliant btw) stdc++ allocator.
Both PR 27000 and bug 26984 are reasons why push/pop will fail currently.
Subject: Re: libstdc++ headers should have pop/push of the visibility around the declarations On 03/04/2006, at 4:57 PM, pinskia at gcc dot gnu dot org wrote: > ------- Comment #92 from pinskia at gcc dot gnu dot org 2006-04-03 > 23:57 ------- > Both PR 27000 and bug 26984 are reasons why push/pop will fail > currently. It's probably OK if the visibility you're pushing is 'default'. At least, it's no worse to push default than it would be to not push anything.
*** Bug 26846 has been marked as a duplicate of this bug. ***
Can this be revisited now? namespaces now can have the visibility attribute, although it has to be present on each opening namespace. Guess sticking __attribute__((__visibility__("default"))) into _GLIBCXX_BEGIN_NAMESPACE and similar macros could do the trick.
Created an attachment (id=11912) [edit] viz patch part one Hey Jakub. Here's a way to start in on this. This does two things: 1) adds default visibility attributes to namespace std namespace std::tr1 namespace __gnu_cxx 2) adds hidden visibility attributes to namespace __gnu_internal There are a couple of things I want to do in addition to this, but these can be added in later. (Such as move as much __gnu_internal into anonymous namespaces, consolidate various internal namespaces into anonymous namespaces or __gnu_internal, relocation tuning, consolidation of visibility schemes between libsupc++ and libstdc++). Testing on so_7 with namespace associations is in progress. tested x86/linux tested x86/linux CXXFLAGS="-fvisibility=hidden" (fails)
Mine.
*** Bug 28449 has been marked as a duplicate of this bug. ***
Subject: Bug 19664 Author: bkoz Date: Thu Jul 20 23:37:27 2006 New Revision: 115632 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115632 Log: 2006-07-20 Benjamin Kosnik <bkoz@redhat.com> Jakub Jelinek <jakub@redhat.com> PR libstdc++/19664 round 1 * acinclude.m4 (GLIBCXX_ENABLE_VISIBILITY): Check it. * configure.ac: Use it. * configure: Regenerate. * docs/html/configopts.html: Document it. * include/Makefile.am: Slip in to c++config. * include/Makefile.in: Regenerate. * include/bits/c++config (_GLIBCXX_VISIBILITY): New. (_GLIBCXX_BEGIN_NAMESPACE): Use it. (_GLIBCXX_END_NAMESPACE): Use it. (_GLIBCXX_BEGIN_NESTED_NAMESPACE): Use it. (_GLIBCXX_END_NESTED_NAMESPACE): Use it. * src/debug.cc: Mark __gnu_internal namespace with hidden visibility attribute. * src/ext-inst.cc: Same. * src/globals_io.cc: Same. * src/globals_locale.cc: Same. * src/ios_init.cc: Same. * src/locale.cc: Same. * src/mt_allocator.cc: Same. * src/pool_allocator.cc: Same. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/Makefile.in trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/docs/html/configopts.html trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/c++config trunk/libstdc++-v3/libmath/Makefile.in trunk/libstdc++-v3/libsupc++/Makefile.in trunk/libstdc++-v3/po/Makefile.in trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/src/ext-inst.cc trunk/libstdc++-v3/src/globals_io.cc trunk/libstdc++-v3/src/globals_locale.cc trunk/libstdc++-v3/src/ios_init.cc trunk/libstdc++-v3/src/locale.cc trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/src/mt_allocator.cc trunk/libstdc++-v3/src/pool_allocator.cc trunk/libstdc++-v3/testsuite/Makefile.in
Subject: Bug 19664 Author: bkoz Date: Fri Jul 28 04:57:34 2006 New Revision: 115790 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115790 Log: 2006-07-27 Benjamin Kosnik <bkoz@wells.artheist.org> PR libstdc++/19664 round 3 * include/Makefile.am (tr1_headers): Add hashtable_policy.h. * include/Makefile.in: Regenerate. * include/tr1/hashtable: Move policy classes into... * include/tr1/hashtable_policy.h: ... this. New. * src/globals_locale.cc: Move contents.... * src/locale_init.cc: ... to here, put in anonymous namespace. * src/Makefile.am: Remove globals_locale.cc. * src/Makefile.in: Regenerate. * src/locale.cc: Convert __gnu_internal to anonymous namespace. * src/debug.cc: Same. * src/ext-inst.cc: Same. * src/mt_allocator.cc: Same. * src/pool_allocator.cc: Same. * include/tr1/random: Convert std::tr1::_Private to anonymous namespace. * include/tr1/random.tcc: Same. * include/tr1/hashtable: Move ::Internal to std::tr1::detail and enclose bits that can actually be internal in in anonymous namespace. * include/tr1/unordered_set: Adjust explicit qualifications for namespace changes. * include/tr1/unordered_map: Same. * include/tr1/cmath: Convert __gnu_internal to nested detail namespace. * include/bits/cpp_type_traits.h: Move __type_type into anonymous namespace. * include/ext/rope: Change _Rope_constants to anonymous namespace. * include/ext/ropeimpl.h: Same. * src/ext-inst.cc: Same. Added: trunk/libstdc++-v3/include/tr1/hashtable_policy.h Removed: trunk/libstdc++-v3/src/globals_locale.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in trunk/libstdc++-v3/include/bits/cpp_type_traits.h trunk/libstdc++-v3/include/ext/rope trunk/libstdc++-v3/include/ext/ropeimpl.h trunk/libstdc++-v3/include/tr1/cmath trunk/libstdc++-v3/include/tr1/hashtable trunk/libstdc++-v3/include/tr1/random trunk/libstdc++-v3/include/tr1/random.tcc trunk/libstdc++-v3/include/tr1/unordered_map trunk/libstdc++-v3/include/tr1/unordered_set trunk/libstdc++-v3/src/Makefile.am trunk/libstdc++-v3/src/Makefile.in trunk/libstdc++-v3/src/debug.cc trunk/libstdc++-v3/src/ext-inst.cc trunk/libstdc++-v3/src/locale.cc trunk/libstdc++-v3/src/locale_init.cc trunk/libstdc++-v3/src/mt_allocator.cc trunk/libstdc++-v3/src/pool_allocator.cc
Fixed.
*** Bug 30900 has been marked as a duplicate of this bug. ***
*** Bug 31459 has been marked as a duplicate of this bug. ***
kdelibs doesn't link with gcc-4.2.0 with hidden visibility. It compiles and links fine with gcc 4.1.2 with patch from Comment #86. That patch was included by gentoo till 4.1.2 and dropped because this bug is supposedly fixed in 4.2.0. I am having difficulty understanding it. How is it fixed if it doesn't even match the functionality provided by one of the earlier proposed patches? Or Is it that the kdelibs-3.5.[67] code needs to change for the new patch in GCC 4.2.0? Where is the problem? The message from kdelibs link is: -------------------------------------- /bin/sh ../libtool --silent --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -Wno-long-long -Wundef -ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W -Wpointer-arith -DNDEBUG -DNO_DEBUG -O2 -O2 -march=k8 -msse2 -msse3 -fforce-addr -pipe -Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor -fno-exceptions -fno-check-new -fno-common -fvisibility=hidden -fvisibility-inlines-hidden -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -Wl,-O1 -Wl,--enable-new-dtags -o libkhtml.la -rpath /usr/kde/3.5/lib64 -version-info 6:0:2 -no-undefined -Wl,--no-undefined -Wl,--allow-shlib-undefined -Wl,--version-script=./libkhtml.map -L/usr/kde/3.5/lib64 -L/usr/qt/3/lib64 -L/usr/lib64 libkhtml_la.all_cc.lo libkhtml_la.all_cpp.lo ./xml/libkhtmlxml.la ./html/libkhtmlhtml.la ./rendering/libkhtmlrender.la ./css/libkhtmlcss.la ./misc/libkhtmlmisc.la ecma/libkjs_html.la ./dom/libkhtmldom.la ../kparts/libkparts.la ../kdeprint/libkdeprint.la ../kutils/libkutils.la ../kwallet/client/libkwalletclient.la /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: ./html/.libs/libkhtmlhtml.a(libkhtmlhtml_la.all_cpp.o): relocation R_X86_64_PC32 against `vtable for DOM::HTMLPreElementImpl' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.2.0/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status make[3]: *** [libkhtml.la] Error 1 make[3]: Leaving directory `/home/tmp/portage/kde-base/kdelibs-3.5.7/work/kdelibs-3.5.7/khtml' make[2]: *** [all-recursive] Error 1 -----------------------------------------------------
(In reply to comment #104) > kdelibs doesn't link with gcc-4.2.0 with hidden visibility. you need a path for pr20218.
I haven't tried the fix in 20218. surprisingly, moving to binutils 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is going on? how did the latest binutils bypass the bug 20218?
(In reply to comment #106) > I haven't tried the fix in 20218. surprisingly, moving to binutils > 2.17.50.0.16.20070511 got rid of that problem. Do you know what exactly is > going on? how did the latest binutils bypass the bug 20218? > Probably because this bug is fixed in the prerelase binutils: http://sourceware.org/bugzilla/show_bug.cgi?id=3666
but comments in bug 20218 say that its fixed in mainline, which means there was a fix put into gcc for hidden visibility. So, are both the fix from prerelease binutils and gcc mainline needed to fix this completely?