MacOSX Debug OpenOffice.org using XCode
Pre conditions : a complete Aqua build see AquaBuild
Contents
Prepare libvcl
rename the vcl output. e.g. on Intel, the outpu tree in vcl is unxmacxi.pro
just do :
mv unxmacxi.pro unxmacxi.pro_backup
Note: rename unxmacxi.pro_back or whatever _* will help to preserve the output even after dmake clean.
rebuild vcl using debug="not_empty_string"
build debut=something
then do :
cd vcl touch aqua/source/gdi/salbmp.cxx build
Supposing the AquaBuild sources are located in ~/SRC680_m220 ( adapt to your tree ) , do :
cd <install_dir>/Openoffice.org\ 2.3.app/Contents/MacOS/
rm -f libvcl* ln -s <AquaBuild_dir>/vcl/unxmacxi.pro/lib/libvcl* .
Note : don't forget the dot !!
Start Xcode
Create a new project
select empty project
Add existing Files
choose e.g. aquavcl_debug in home dir
then right click on aquavcl_debug icon (on top left) and select "add existing files"
choose <AquaBuild_dir/vcl> folder click on add
be sure to check "Create Folder References for any added folders"
vcl directory should appear as subfolder of aquavcl_debug
Add New Executables
now right click on Executables (on left ) and choose Add ->New custom executable
Fill the fields as follow :
Executable name : OpenOffice.org
Executable Path : <install_dir>/OpenOffice.org 2.3.app (you will edit this later - in XCode 2.4 it must have a value to enable finish)
Click on finish when done
Just after, a window should appear : "Executable OpenOffice.org Info"
Executable path should be <install_dir>/OpenOffice.org 2.3.app/Contents/MacOS/soffice_bin (rename soffice.bin to soffice_bin)
Check Custom Custom Directory and put :
<install_dir>/OpenOffice.org 2.3.app/Contents/MacOS
Next step is modify the Info.plist in the Bundle : right click on the bundle, and select Display package content, click on Contents, and double click on Info.plist
Property List Editor will open the file, and you'll be able to modify CFBundleExecutable entry : change soffice.bin for soffice_bin.
Then save the change, and close Property List Editor.
On menubar, run debugger and enjoy debugging :)
Change Debugging preferences
Xcode seems to have problems with breakpoints in not yet loaded libraries. To change this malbehavior go to Preferences -> Debugging and make sure that "Load symbols lazily" is unchecked.
FAQ
Is it possible to build the complete set with symbols included ?
Currently not possible, and not advised.
is it possible to build some modules with symbols ?
Yes, and that's the simplest way to proceed. Some modules, like sal and vcl can be rebuilt using debug.
Example:
To rebuild sal with symbols included, do:
[bash,N]
cd sal
rm -rf unxmacxp.pro
build debug=true
and recopy the libs into the bundle. gdb will display the symbols, and make your life easier.
Note: debug string is tested, and DEBUG is active when debug string is not empty. So debug=t works too.
How change gdb options, and use e.g. -g -ggdb or -gdwarf-2 ?
To rebuild the module, you just have to modify the option in solenv/inc/unxmacx.mk, replacing -g with -ggdb
Known issues
Sometimes a build error, or a runtime error, may be seen in the normal build, but the error goes away when --enable-debug is used or if the module is compiled with debug=true.
The DEBUG build turns off optimisation, so this is a hint that compiler optimisation causes the error.
The error might be due to incorrect code or a compiler fault. Such errors might not be seen on all platforms,
and might not be seen in different compiler versions on one platform.
If the code can not be fixed there is a workaround using NOOPTFILES to build specified files with no optimisation.
Example:
jvmfwk on Mac OS X: build jvmfwk in m183 on Mac OS X Intel leads to Bus Error when javaldx is run.
Solution: use trial and error to rebuild individual files with debug=true. This proves the problem lies with vendorbase.cxx
Have a look in sc/source/core/data/makefile.mk for an example to use NOOPTFILES
To solve our problem: just add: NOOPTFILES= $(SLO)$/vendorbase.obj in the corresponding makefile.
Take care in case some .IF is needed to prevent interference with other platforms.
There's some additional information around debugging on Christians Page User:CL#2006-09-03
Run svdem
We want to run the demonstration programs called "svdem". There are a couple of binaries called "svdem", which area they cover is still somewhat unclear to me, I hope some of you guys can shed some light here. But hey, this is a wiki! Just correct here:-).
svdem from VCL
To have the VCL Testprogram build you have to do:
[FIXME] replace this scetion with the same, but about svdem from svtools
cd vcl; build --all
This should have created a file called "svdem" here: vcl/unxmacxp.pro/bin/svdem. If you managed to build these binaries, you are nearly there. What you need now, is a wrapper directory structure to make this binary a fellow Mac OSX application. I mean the ones which have this structure:
svdem.app/ svdem.app/Contents svdem.app/Contents/Info.plist svdem.app/Contents/MacOS svdem.app/Contents/MacOS/applicat.rdb svdem.app/Contents/MacOS/svdem
You can basically create this structure anywhere you want. And you can link-in the file you just created (svdem). So you build up this structure once and link-in the freshly created svdem there:
ls -l svdem applicat.rdb svdem -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/svdem applicat.rdb -> /opt/src/openoffice/src680-m202/vcl/unxmacxp.pro/bin/applicat.rdb
Now only the Info.plist file is missing, so here we go:
[xml,N]
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>CFBundleDevelopmentRegion</key> <string>English</string> <key>CFBundleDisplayName</key> <string>SvDem</string> <key>CFBundleExecutable</key> <string>svdem</string> <key>CFBundleIdentifier</key> <string>com.yourcompany.svdem</string> <key>CFBundleInfoDictionaryVersion</key> <string>6.0</string> <key>CFBundlePackageType</key> <string>APPL</string> <key>CFBundleSignature</key> <string>????</string> <key>CFBundleVersion</key> <string>1.0</string> <key>LSRequiresCarbon</key> <true/> </dict> </plist>
If you created the directory structure properly you can do './svdem' in the 'svdem.app/Contents/MacOS/' directory. You should see the svdem coming up.
svdem from svtools
- Copy the application package you created for the vcl svdem.
- Source your MacOSX[PPC-X86]Env.Set.sh
- Go into svtools/workben
- build svdem using dmake in the workben directory
- link the svdem and applicat.rdb from Contents/MacOS to the ones located in svtools/unxmacxp.pro/bin
You are done: you can now source your environment and run svdem using your usual shell.
Links
On the wiki : Debugging OpenOffice.org
Xemacs : Michael Sicotte wrote a very usefull blog entry about debugging OOo with XEmacs and GDB on Mac OS X