MacOSX Debug using XCode

From Apache OpenOffice Wiki
Revision as of 09:41, 20 March 2013 by Hdu (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

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 (in all modules btw). Then, just do :

mv 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.

build debug=true

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\

rm -f libvcl*

cp <AquaBuild_dir>/vcl/* .

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)

Prepare Xcode

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/

after having adapted PATH_TO_AOO_SOURCE to the path to the source directory of course.

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

XCode debug add existing files.jpg

Add New Executables

now right click on Executables (on left ) and choose Add ->New custom executable

XCode debug add new executable.jpg

Fill the fields as follow :

Executable name :

Executable Path : <install_dir>/ (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 Info"

Executable path should be <install_dir>/ (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.

XCode debug preferences.png


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:

[bash,N] cd sal rm -rf 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/, 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.


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/ 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/ 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:

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/
applicat.rdb -> /opt/src/openoffice/src680-m202/vcl/

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" "">
<plist version="1.0">

If you created the directory structure properly you can do './svdem' in the '' 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]
  • 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/

You are done: you can now source your environment and run svdem using your usual shell.


On the wiki : Debugging

Xemacs : Michael Sicotte wrote a very usefull blog entry about debugging OOo with XEmacs and GDB on Mac OS X

Personal tools