MacOSX Debug OpenOffice.org using XCode
Pre conditions : a complete Aqua build see AquaBuild
Prepare a module with debug info
IMPORTANT: all instructions below do concern vcl, but are usable for other modules (e.g. extensions )
rename the vcl output. e.g. on Intel, the output tree name is unxmacxi.pro (in all modules btw). Then, 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". The effect is to include symbols in the library, for gdb.
then do :
cd vcl touch aqua/source/gdi/salbmp.cxx build debug=t
Supposing the AquaBuild sources are located in ~/DEV300_m0 ( adapt to your tree ) , do : cd <install_dir>/OpenOffice\OpenOffice.app/Contents/MacOS/
rm -f libvcl* cp <AquaBuild_dir>/vcl/unxmacxi.pro/lib/libvcl* .
Note : don't forget the dot !!
Simply soft-linking libraries into its target location doesn't work anymore (it used to work until CWS sb71 got integrated)
XCode allows you to see OpenOffice types conveniently while you are debugging. To enable this add a line to ~/.lldbinit
command script import PATH_TO_AOO_SOURCE/main/solenv/inc/lldb4aoo.py
after having adapted PATH_TO_AOO_SOURCE to the path to the source directory of course.
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.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.app/Contents/MacOS/soffice_bin (rename soffice.bin to soffice_bin)
Check Custom Custom Directory and put :
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.
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.
To rebuild sal with symbols included, do:
rm -rf unxmacxp.pro
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
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.
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
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 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.
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