I know that visibility support is still unsafe, although upstream GCC and KDE continue saying that it's all well... I know GCC 4.1 seems to fix the -fvisibility-inlines-hidden problem with -fPIC.. but seems like #pragma still have issues. I'm going to attach a (bzip2 compressed) copy of the preprocessed output generated by rubytag++, that, once compiled, fails badly: flame@enterprise ~/tmp $ gcc -shared -fPIC rubytagpp.ii -o rubytagpp-test.so /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1-pre20060517/../../../../x86_64-pc-linux-gnu/bin/ld: warning: creating a DT_TEXTREL in object. /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1-pre20060517/../../../../x86_64-pc-linux-gnu/bin/ld: /tmp/ccZUhVew.o: relocation R_X86_64_PC32 against `rb_define_module' can not be used when making a shared object; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1-pre20060517/../../../../x86_64-pc-linux-gnu/bin/ld: final link failed: Bad value collect2: ld returned 1 exit status Hope this can help to find what it's still wrong with it. Diego
Created attachment 87353 [details] rubytagpp.ii.bz2
Here's a reduced testcase. I'll try to do some debugging and talk to upstream to make sure this isn't intended behaviour...I'm sure it isn't :) #pragma GCC visibility push(hidden) void rb_check_type (int, int); class AudioProperties {}; AudioProperties * ruby2TagLib_AudioPropertiesPtr (int rval) { do { rb_check_type (rval, 0x22); } while (0); }
Actually, I think that testcase just shows another way to get a textrel...I'll have to look into this more.
*** Bug 170289 has been marked as a duplicate of this bug. ***
looks like it'll prob stay broken until gcc-4.2.0 is released ... the required changes are just too invasive for any one here to watch over
Do we want to keep this open until gcc-4.2 is stable? (Its in the tree atleast, and I'm pretty sure Diego was running ~arch to hit this bug when he did)
I'd close this since anyway 4.1 is broken a lot regarding visibility, so it's not much of a problem.
Fixed in newer versions of gcc.