Apache OpenOffice (AOO) Bugzilla – Issue 77967
Xcode can not debug binaries with '.' in its name
Last modified: 2007-10-30 09:12:43 UTC
This is a follow-up to issue 73693, where we discussed the potential mozilla-like renaming of soffice.bin to soffice-bin to fix this issue. Known problems with this approach: * rtl bootstrap code only checks for ".exe" and ".bin", resulting in sofficerc not being treated as bootstrap file (see sal/rtl/source/bootstrap.cxx). * potentially crash reporter tooling and/or other places may rely on '.' as extension delimiter. Another proposal is to (generally) rename "soffice" script to "soffice.sh" and "soffice.bin" to "soffice". The problem with this approach is that AFAIK the UNO bootstrap code, which tries to locate the office somewhere on the system (link to some spec appreciated), expects a symlink named "soffice" to be in the path and pointing to the soffice shell script inside the installation. So this link would actually have to point to soffice.sh instead, which needs also to be remembered by users trying to override the system default "soffice".
Some info on the UNO bootstrap process can be found here: http://udk.openoffice.org/common/man/ spec/transparentofficecomponents.html.
Also, the executable program/soffice to start OOo should IMO be considered part of OOo's stable client-facing (end user, client apps, ...) interface.
Hmm, it seems a number of tools on Mac OS X (including gdb) expect the binary to reside in <bundle>/ MacOS directory directly, so we just renamed "program" to "MacOS" in issue 73693. Also, when thinking of bundled versions of OO.o, the name "program" is rather unusual on a unix system - wouldn't most people expect applications to reside in some directory named "bin" ?
Re renaming "program" -> "MacOS": Might be OK to choose deviating names on not-yet-settled platforms (though it can complicate otherwise platform-independent things). I was more objecting against renaming "soffice" -> "soffice.sh" on all Unix-like platforms.
Ah, o.k. So which kind of code/tools might be affected from renaming internal name "soffice.bin" to "soffice- bin" ? * rtl::Bootstrap was already mentioned * I would be surprised if the crash reporting would cut off any extension, but we should verify * testtool (for killing a hanging office instance) ? * more .. ? Another potential solution is to get rid of the script file also for the X11 version of Mac OS X, as we can not use the script for aqua anyway: environment variables can be set in the Info.plist (IIRC), but replacing javaldx (if necessary) might be hard.
bei->obrmac: right crash debugging uses the complete filename and thus matching against older reports breaks if filenames are changed (at least mostly as there is some fuzzy matching involved which might led to some matches still being possible) leading to more costs to find duplicates.
Gregor, Bernd, what about 'crashdebug.pl'? Is it still in use? That script does a lot of ugly things whith extensions. (AFAIK it has to guess how a binary in an install set was named before delivering it, because it has to find it in the corresponding source tree. Rename during deliver rarely is a good idea ...)
BEI->RT: the binary will just send the name with which it was installed in the crashreport XML data which will be used for matching. If we do have renamed binaries we can not match correctly anymore no matter where the renaming happened. Crashdebug.pl is just being used much much later on in development after the user installation was done and the crash occurred and was send and is thus completely out of the game here when discussing if, where and how to rename the binary for the user installation. Can´t those Xcode people not just make their stuff work instead of everyone having to introduce ugly workarounds? BEI->obrmac: if you use an soffice.sh approach some more work has to be done insided the script as that is pretty much generic multi purpose thing where inside the script variables are set according to via which link or other means the script was being called calling different *.bin excutables depending on those variables at the end and you´d have to reflect the thing that you can now call soffice.sh instead etc. And on the other hand IMHO this is not a good idea as people may still want to have $OFFICE_HOME/program in their $PATH and would try to use 'soffice' on the command line not knowing that there is an soffice.sh which wouldn´t work than. Besides that the fact that the binary is being renamed remains.
Well I was just thinking that in the crash report backend or into the crash reporter itself we can of course integrate some ugly code to rename soffice-bin to soffice.bin before sending the report or when receiving it. But well :-( So well I would thus like to see that soffice-bin thing only platform specific for the mac and the other platforms staying the same as for mac we don´t have crash report data anyway yet, so that matching problems disappears there.
Hey, isn't the existance of the soffice script and thus the necessary renaming of the binary to "soffice.bin" an ugly workaround by itself already ? ;-). We do all those ugly things (rename in deliver etc.) on all platforms already. The cleanest solution seems to be to get rid of the start scipt on Mac OS X completly before we start collecting crash reports. We need to fix the problems evolving from not using the script for the aqua version anyway.
I think we should just live with this issue and report it to Apple/ask them on WWDC.
GH->Bei Please don't rename soffice-bin to soffice.bin when sending the reprot. This would result in even more guessing in crashreport.pl In crashreport.pl there is also one place which has to be changed
Apple confirmed this is an XCode bug. I reported then bug number 29756612 on Radar. Waiting for more news ( I'll paste any information asap )
+ add aqua keyword, more easy to trace
The bug is fixed in XCode3.0 but will probably never be backported Since the Apple Radar ( i.e. Apple IZ ) is not pubic, I no longer use it, and the most simple way to verify, is to check if the the next XCode2.5 (coming soon) will contain or not the fix. -> Wontfix
Closing Todo: don't forget to complete the issue, if ever the bug is fixed a day.