[util-issues] [Issue 64903] testtools regcomp signal 1 1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64903 --- Additional comments from [EMAIL PROTECTED] Fri Apr 11 16:54:23 + 2008 --- OOo-2.4.0; GCJ 4.1.2 configured with: ./configure --prefix=/opt/OpenOffice --libdir=/opt/OpenOffice/lib64 --disable-gnome-vfs --disable-build-mozilla --enable-gcjaot --with-openldap --with-system-zlib --with-system-jpeg --with-system-expat --with-system-freetype --with-system-xerces --with-system-xalan --with-system-xrender-headers --with-system-libxml --with-system-libxslt --with-system-curl --with-system-boost --with-system-sndfile --with-java=gij --with-use-shell=bash --with-build-version=Built locally on phoenix --with-package-format=portable 21 | tee conf.log I'm using locally prebuilt mozilla (stashed away after a previous attempt at a build) and the provided unowinreg.dll (the MinGW cross-compile rule somehow results in /usr/include getting onto the include path, blowing up MinGW). I didn't find a findhome class anywhere in the build tree. GCJ sets java.home=/usr and I have previously established a symlink /usr/lib/amd64/client/libjvm.so to libgcj in order to get (something else in OOo) to build. - 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]
[util-issues] [Issue 64903] testtools regcomp signal 1 1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64903 --- Additional comments from [EMAIL PROTECTED] Thu Apr 10 16:24:46 + 2008 --- I'm actually attempting a 64bit build with GCJ. It has been confirmed that the Java VM, (actually libgcj) is being found and used. (I was previously getting an error to the effect of Java VM not found until I made a symlink /usr/lib/amd64/client/libjvm.so - /lib64/libgcj.so.7 ) - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
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] Wed Apr 9 16:59:48 + 2008 --- 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. - 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]
[util-issues] [Issue 64903] testtools regcomp signal 1 1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64903 --- Additional comments from [EMAIL PROTECTED] Wed Apr 9 17:05:33 + 2008 --- Yes, non-Java libraries work, if by non-Java you mean does regcomp work at all? -- C/C++/whatever-the-ones-mentioned-below-use libraries work. I still have the half-built tree, so if you can tell me how to test for non-Java libraries working, I'll try it. Here's the part of my build log leading up to the error: echo ../../unxlngx6.pro/lib ../../unxlngx6.pro/lib cp -p /var/tmp/OOo-build/solver/680/unxlngx6.pro/bin/udkapi.rdb ../../unxlngx6.pro/lib/uno_types.rdb regmerge ../../unxlngx6.pro/lib/uno_types.rdb / ../../unxlngx6.pro/bin/bridgetest.rdb mkdir ../../unxlngx6.pro/misc/bridgetest/ cp -f /var/tmp/OOo-build/solver/680/unxlngx6.pro/bin/types.rdb ../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb regcomp -register -r ../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb -c javaloader.uno.so \ -c javavm.uno.so -c stocservices.uno.so javaloader.uno.so javavm.uno.so stocservices.uno.so register component 'javaloader.uno.so' in registry '../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb' succesful! register component 'javavm.uno.so' in registry '../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb' succesful! register component 'stocservices.uno.so' in registry '../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb' succesful! mkdir ../../unxlngx6.pro/lib/ mkdir: cannot create directory `../../unxlngx6.pro/lib/': File exists cd ../../unxlngx6.pro/lib regcomp -register -br uno_types.rdb -r uno_services.rdb\ -c acceptor.uno.so \ -c bridgefac.uno.so \ -c connector.uno.so \ -c remotebridge.uno.so \ -c uuresolver.uno.so \ -c bridgetest.uno.so \ -c cppobj.uno.so \ -c stocservices.uno.so \ -c constructors.uno.so acceptor.uno.so bridgefac.uno.so connector.uno.so remotebridge.uno.so uuresolver.uno.so bridgetest.uno.so cppobj.uno.so stocservices.uno.so constructors.uno.so register component 'acceptor.uno.so' in registry 'uno_services.rdb' succesful! register component 'bridgefac.uno.so' in registry 'uno_services.rdb' succesful! register component 'connector.uno.so' in registry 'uno_services.rdb' succesful! register component 'remotebridge.uno.so' in registry 'uno_services.rdb' succesful! register component 'uuresolver.uno.so' in registry 'uno_services.rdb' succesful! register component 'bridgetest.uno.so' in registry 'uno_services.rdb' succesful! register component 'cppobj.uno.so' in registry 'uno_services.rdb' succesful! register component 'stocservices.uno.so' in registry 'uno_services.rdb' succesful! register component 'constructors.uno.so' in registry 'uno_services.rdb' succesful! regcomp -register -br ../../unxlngx6.pro/lib/uno_types.rdb -r ../../unxlngx6.pro/lib/uno_services.rdb \ -c javaloader.uno.so -c javavm.uno.so javaloader.uno.so javavm.uno.so register component 'javaloader.uno.so' in registry '../../unxlngx6.pro/lib/uno_services.rdb' succesful! register component 'javavm.uno.so' in registry '../../unxlngx6.pro/lib/uno_services.rdb' succesful! regcomp -register -br ../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb -r ../../unxlngx6.pro/lib/uno_services.rdb -c \ file:///var/tmp/OOo-build/testtools/source/bridgetest/../../unxlngx6.pro/class/testComponent.jar \ -env:URE_INTERNAL_JAVA_DIR=file:///var/tmp/OOo-build/solver/680/unxlngx6.pro/bin file:///var/tmp/OOo-build/testtools/source/bridgetest/../../unxlngx6.pro/class/testComponent.jar dmake: Error code 139, while making '../../unxlngx6.pro/lib/uno_services.rdb' - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
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] Tue Apr 8 16:29:18 + 2008 --- 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. - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=84965 User jcb62281 changed the following: What|Old value |New value Attachment is patch| |Created an attachment (id= | |52660) patch to disable -f | |visibility-inlines-hidden | |on amd64 Linux --- Additional comments from [EMAIL PROTECTED] Tue Apr 8 16:30:43 + 2008 --- Created an attachment (id=52660) patch to disable -fvisibility-inlines-hidden on amd64 Linux - 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]
[util-issues] [Issue 64903] testtools regcomp signal 1 1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=64903 User jcb62281 changed the following: What|Old value |New value CC|'hjs,jl' |'hjs,jcb62281,jl' --- Additional comments from [EMAIL PROTECTED] Tue Apr 8 16:42:35 + 2008 --- I'm having a similar problem on amd64 Linux; the build fails while running regcomp -register -br ../../unxlngx6.pro/misc/bridgetest/bootstrap.rdb -r ../../unxlngx6.pro/lib/uno_services.rdb -c file:///var/tmp/OOo-build/testtools/source/bridgetest/../../unxlngx6.pro/class/testComponent.jar -env:URE_INTERNAL_JAVA_DIR=file:///var/tmp/OOo-build/solver/680/unxlngx6.pro/bin dmake reports Error code 139 which corresponds to regcomp having died with a SIGSEGV. Somewhat usefully, amd64 Linux records segfaults in the kernel log. This is the log entry: localhost kernel: regcomp.bin[23063]: segfault at 478 rip 2e1c2c88 rsp 41003240 error 4 Where do I start debugging this? - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
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:17:19 + 2008 --- 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.0 -0500 +++ conftest.s.pass 2008-04-05 00:30:53.0 -0500 @@ -46,7 +46,7 @@ movq%rbx, %rsi movq%rsp, %rdi .LEHB1: - call _ZNSt19basic_istringstreamIcSt11char_traitsIcESaIcEEC1ERKSsSt13_Ios_Openmode + call [EMAIL PROTECTED] .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). - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=84965 User jcb62281 changed the following: What|Old value |New value CC|'cmc,hr,hub,kendy'|'cmc,hr,hub,jcb62281,kendy | |' - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
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 + 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]
[tools-issues] [Issue 85398] mws_ooh680: Your gcc is no t -fvisibility-inlines-hidden safe. Try with - -with-stlport
To comment on the following update, log in, then open the issue: http://www.openoffice.org/issues/show_bug.cgi?id=85398 User jcb62281 changed the following: What|Old value |New value CC|'kendy,kz,rene' |'jcb62281,kendy,kz,rene' --- Additional comments from [EMAIL PROTECTED] Sat Apr 5 18:34:30 + 2008 --- I think the given patch is suboptimal--it disables the visibilty feature completely when the problem is certain to exist only with -fvisibility-inlines-hidden; is there no way to use -fvisibility=hidden but not -fvisibility-inlines-hidden? I've made longer comments explaining what I think the cause of this is on Issue 84965. In a nutshell: -fvisibility-inlines-hidden causes GCC to emit relocations that shared objects on amd64 are not allowed to use. This appears to be an unavoidable consequence of what -fvisibility-inlines-hidden is intended to do, and the only bug in GCC here is that it doesn't detect that -fvisibility-inlines-hidden and -fPIC conflict on amd64 and give a more useful error. (In other words, trying to hide all evidence of inlines prevents truly making position-independent code, which x86-64 shared objects are required to be.) - 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]
[xml-issues] [Issue 84965] m241: link problem with gc c-4.2.1
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 19:09:25 + 2008 --- 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. - 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]
