Development/FAQ/pt-br

How do I debug LibreOffice?
The crucial bit is to pass --enable-debug to autogen.sh. See Development/How to debug for details and help.

What are those #iXXXX#/fdo#XXXX/etc. comments?

 * #XXXXXXX# refers to StarDivision internal bugtracker, and are not publicly available, so might as well be removed from the source
 * b#XXXXXX# refers to Sun internal bugtracker, and are not publicly available, so might as well be removed from the source
 * cp#XXXXXX refers to the Collabora internal bugtracker, and are not publicly available, so might as well be removed from the source
 * #iXXXXXX# or i#XXXXXX refers to OpenOffice.org/Apache Open Office bugids, e.g. #i100000# is https://issues.apache.org/ooo/show_bug.cgi?id=100000
 * rhbz#XXXX refers to RedHat bugids, e.g. is https://bugzilla.redhat.com/show_bug.cgi?id=680460
 * #nXXXXXX# or n#XXXXXX or preferably bnc#XXXXXX refers to Novell bugids, e.g. #n672421# is https://bugzilla.novell.com/show_bug.cgi?id=672421
 * fdo#XXXXX refers to Freedesktop.org bugids, e.g. is https://bugs.freedesktop.org/show_bug.cgi?id=32275
 * This includes non-LO bugs that are relevant to LO, e.g. and old LibreOffice bugs (before January 2015)
 * tdf#XXXXX refers to The Document Foundation’s own instance of Bugzilla, e.g. is https://bugs.documentfoundation.org/show_bug.cgi?id=32275
 * lp#XXXXXX refers to launchpad, for example: https://launchpad.net/bugs/775608
 * abi#XXXXXX refers to AbiSource (Abiword) bugtracker, for example: http://bugzilla.abisource.com/show_bug.cgi?id=123456
 * boost#XXXXXX refers to Boost's bugtracker, for example: https://svn.boost.org/trac/boost/ticket/123456
 * deb#XXXXXX refers to Debian's bugtracker, for example: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=123456
 * gnome#XXXXXX refers to Gnome's bugtracker, for example: https://bugzilla.gnome.org/show_bug.cgi?id=123456
 * icu#XXXXXX refers to ICU's bugtracker, for example: http://bugs.icu-project.org/trac/ticket/123456
 * kde#XXXXXX refers to KDE's bugtracker, for example: https://bugs.kde.org/show_bug.cgi?id=123456
 * moz#XXXXXX refers to Mozilla's bugtracker, for example: https://bugzilla.mozilla.org//show_bug.cgi?id=123456
 * py#XXXXXX refers to Python's bugtracker, for example: https://bugs.python.org/issue123456
 * ofz#XXXXXX refers to the OFZ internal bug tracker (Google OSS fuzzer, see https://github.com/google/oss-fuzz ) (bug tracker publicly available after a few days/weeks at chromium.org)
 * cid#XXXXXX or coverity#XXXXXX refers to the Coverity Bugs.

What are all those tests: unit tests, smoketests, subsequent tests?
The question was answered by Bjoern Michaelsen in a posting to the mailinglist: http://lists.freedesktop.org/archives/libreoffice/2011-March/009834.html

A top-level "make check" will first do a full build, then run all the subsequent tests, while a top-level "make subsequentcheck" will only run all the subsequent tests.

More information on unit tests is to be found here and on subsequent tests: here.

The smoketest failed, how do I debug that
If make dev-install, or building smoketestoo_native fails, then the install that failed the smoketest remains in You can run the smoketest manually and look at the pretty green/red report cells to see what exactly failed. turn off macro security, e.g. and close office click the start smoketest button

Another alternative is to start  ahead of time and ask the smoketest to connect to that instance instead of starting one itself (see ). You can then run the  under debugger control. The only problem is that  would normally overwrite the   just started with a new installation set, due to the dependency of   on   in. So, something like the following should work:

I'd like to build LibreOffice, but I'm only interested in Writer. Can I just build Writer without the rest?
The short answer is no.

The long answer is that, the individual application modules in LibreOffice (Writer, Calc, Draw, Impress, etc) have much of their code shared so that the topmost module part consists only of less than 10% of the whole code. So, even if you managed to somehow skip building of some of these apps, it wouldn't significantly reduce the overall build time.

On top of that, the whole suite is designed with the assumption that all application modules are present at all times. So, if some of the apps are not there, it may create some weird nasty issues that nobody else could help you with.

On Windows, the build failed with an internal error in the compiler
fatal error c1001: An internal error has occured in the compiler You have to check if you have the latest update for Visual Studio.

Check the update on Microsoft search.