Apache OpenOffice (AOO) Bugzilla – Issue 84965
m241: link problem with gcc-4.2.1
Last modified: 2008-04-09 17:59:49 UTC
xmloff fails to link using gcc 4.2.1 and -fvisibility=hidden with this error: /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld: ../unxlngx6.pro/slo/layerexport.o: relocation R_X86_64_PC32 against `exportXForms(SvXMLExport&)' can not be used when making a shared object; recompile with -fPIC this is on openSUSE 10.3 x86_64. I have a patch that I can hopefully attatch after submitting.
Created attachment 50645 [details] buildfix-xmloff-exportxforms.diff
Heiner, can you please comment: I wonder why the symbols that the patch exports need to be exported. It seems that they are not needed as otherwise even other builds should have a problem.
FWIW I don't need this patch, does that compiler pass the configure tests in newportstl, i.e. can we rule out a broken compiler ?
cmc: That was my first thought as well - but jcn confirmed that the compiler is safe wrt. the visibility-inlines-hidden :-( mba: This really seems to be bound to an exact gcc version, I'm fine with 4.1.2 as well. jcn: I wonder - this appeared for the first time with m241, is that right, please?
@mba: No idea yet, shouldn't be necessary. As Jan said, seems to be gcc version specific.
In general I'm fine with code changes that - though basically unnecessary - help to build the code on a certain platform. But I hesitate to add something just to please a particular, yet-not-officially-supported version of a particular compiler.
I had the problem here with stlport disabled and m242. openSUSE 10.3 compilers on x86_64.
kendy: yes, m241 was the first. As hub noted, the compiler I used is openSUSE 10.3's default compiler.
I'm having a similar problem on LinuxFromScratch with gcc 4.1.2 and the system STL. The compiler fails configure's tests, removing -fvisibility-inlines-hidden results in the following one-line change in the assembler output: --- conftest.s 2008-04-05 00:32:07.000000000 -0500 +++ conftest.s.pass 2008-04-05 00:30:53.000000000 -0500 @@ -46,7 +46,7 @@ movq %rbx, %rsi movq %rsp, %rdi .LEHB1: - call _ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode + call _ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode@PLT .LEHE1: .L7: .L8: Apparently, on amd64, calls within a shared object MUST be indirected through the PLT. Attempting to avoid doing so results in a PC-relative relocation being required, but amd64 forbids the use of such relocations in shared objects (position independence is enforced, absolutely). Using STLport might get around this, but only at the cost of *duplicating the STL code in each module that needs it* (which surely wastes more space than the long symbol names in the PLT). Really, GCC should either give an error or just ignore -fvisibility-inlines-hidden in the case of building a shared object on amd64. It doesn't--GCC appears to trust that you know what you're doing, even when you're asking for code to be compiled in a way such that linking will be impossible. I'm not sure if this issue also extends to -fvisibility=hidden in the general case or not (I hope not--the control it provides is over exported symbols sounds very nice).
I've thought about this a bit more and I think I may know what's going wrong, and why my GCC and system STL fail configure's test. Apparently, on AMD64 you can safely hide anything that is defined in the same shared object where it is used (so -fvisibility=hidden shouldn't break anything; the keyword here is "shouldn't"--any symbol that does somehow get referenced externally will break linking and will need to be exported). But any and all references between shared objects *MUST* go through the PLT. (This allows the aggressive address space randomization that amd64 Linux does to work. The same shared object will be mapped at different addresses in different processes. Thus, any relocation that is supposed to reference another shared object is guaranteed to break as soon as two processes share the same SO. So all cross-loadable-module references must go through the PLT.) -fvisibility-inlines-hidden in the case of configure's test results in the object trying to hide an internal reference to ios_base::openmode that the inlined constructor for istringstream uses. This symbol lives in the C++ runtime library (a separate shared object), thus it can be referenced *ONLY* through the PLT. But -fvisibility-inlines-hidden asks GCC to reference it directly. GCC foolishly obliges and linking fails because "you can't do that". At this time, I think the only real solution to this is to build without -fvisibility-inlines-hidden on amd64 and simply take the increased binary size as a cost of the platform ABI and the platform's "security features". (One of the points of ASLR is to make it impossible to call cross-module without the dynamic loader's help, which exploit code won't have. (The loader is also mapped at a random address in each process, so an attacker can't just call into it either.) So, to gain some extra protection from buffer overflows, "neat tricks" that require SO's to reference each other directly are forbidden. We can argue this choice all day, but it's already been made, and we're stuck with it on amd64.) (Extra note: I encountered this trying to build the 2.4.0 release.)
In the DEV300 series on a buggy -fvisibility-inlines-hidden configure auto deselects the use of -fvisibility-inlines-hidden so is this issue now just a duplicate of issue 85398 ?
I suspect that this and Issue 85398 share the same root cause. (Trying to avoid using the PLT, where use of the PLT is mandatory.) Some of the other comments there reference similar problems on S/390, except that the S/390 linker apparently doesn't bail out with an error (!!) when asked to do a similarly impossible link. I have prepared an experimental patch that simply removes -fvisibility-inlines-hidden on x86-64. I'll post it if I succeed in building with it.
I doubt anyone will welcome a patch that simply removes the hidden-visibility for everyone :-( suse and redhat patch the vanilla 4.2.1 wrt. visibility and both backports suffer from different categories of buggyness in different visibility areas. The RH and vanilla 4.2.1 and 4.3.0 doesn't exhibit this problem. (while the RH one 4.1.2 suffered from a different nasty runtime only problem) I strongly suspect that this is a dup of 85398 *** This issue has been marked as a duplicate of 85398 ***
I've run into other build problems; so I'll go ahead and post the patch. It removes only the -fvisibility-inlines-hidden flag; modules that use -fvivsibility=hidden continue to do so. Probably a better solution would be to make the configure tests for -fvisibility=hidden and -fvisibility-inlines-hidden set separate variables.
Created attachment 52660 [details] patch to disable -fvisibility-inlines-hidden on amd64 Linux
jcb62281: this issue has been marked as a duplicate. Please proceed in issue 85398.
mba: Well, but the other bug is closed as well, so maybe this one can be used as a follow-up bug (the other is integrated IIRC). jcn: We have something like you propose (one more variable) in ooo-build, please see http://svn.gnome.org/viewvc/ooo-build/trunk/patches/src680/buildfix-x86-64-visibility-workaround.diff?view=markup
So if the other issue is fixed and you still have something to add for *this* issue then either the other one is *not* fixed or this one isn't a duplicate. :-) I'm confused now. So if there is still something we should fix for this issue, please reopen it. I'm also not the one to decide whether we should accept the patch, I will need to ask Heiner or someone else.
I'm currently building DEV300 m0 on AMD64 with vanilla gcc-4.2.3 and compiler STL and had no problem at all in xmloff. The problem seems to be very compiler version specific. My suggestions is to at least warn in configure for proven broken gcc versions on this platform with a reference to this issue (where one can find the patch). I don't think we should export more symbols by default or disable the visibility switches just for a few broken compilers, IMHO.
hr: If the patch in issue 85398 is integrated in DEV300 m0, you won't see this because that patch disables visibility completely if -fvisibility-inlines-hidden doesn't work. What does HAVE_GCC_VISIBILITY_FEATURE get set to in your build? I may need to make a new issue for this.