To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=84965
------- Additional comments from [EMAIL PROTECTED] Sat Apr 5 06:51:35 +0000 2008 ------- 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.) --------------------------------------------------------------------- Please do not reply to this automatically generated notification from Issue Tracker. Please log onto the website and enter your comments. http://qa.openoffice.org/issue_handling/project_issues.html#notification --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
