Linuxと*BSDシステムにおけるLibreOfficeビルドのヒントとコツ

From The Document Foundation Wiki
Jump to: navigation, search
本ページはGlobal Wikiからの有志による翻訳ページです。未翻訳があることや内容が古い場合があります。最新化、翻訳にご協力お願いします。
日本語独自の情報についてまとめることを目的として、日本語コミュニティによって運営されているページとして 日本語コミュニティ独自ページ があります。
URLが wiki.documentfoundation.org/JA で始まっていて、カテゴリーがJAのページです。
そちらもご利用ください。

注意:このページのオリジナルはBuilding LibreOffice on Linux and *BSD systems: Tips and Tricks2016-12-04T14:57:46の版からコピーしたものです。

原文は逐次改定されるので、定期的に原文を参照して差分を更新し、ずれることがないようにお願いします。なお差分更新をかけた場合は上の日付も修正しておいてください。

ビルドの依存

追加の情報はページ Linuxビルドの依存関係 で見付かるかもしれません。

一般的に、 LibreOffice をビルドする一番簡単な方法は Linux上で行います。

最初にあなたはビルドの依存関係を構築する必要があります:

  • Debian/Ubuntuでは: sudo apt-get build-dep libreoffice
  • OpenSUSE 11.4+では: sudo zypper si -d libreoffice
  • OpenSUSE 11.4+では: sudo zypper si -d libreoffice
  • Fedora 22+ & 派生作品では: sudo dnf builddep libreoffice
  • Fedora 21+ & 派生作品では: sudo yum-builddep libreoffice
  • On DragonFly cd /usr/dports/editors/libreoffice && make patch
  • On FreeBSD cd /usr/ports/editors/libreoffice && make patch
  • On NetBSD cd /usr/pkgsrc/misc/libreoffice && make depends

注意、これらのコマンドは必要とされるすべてのものをインストールしなくても良いかもしれません、なぜならばそれらはディストリビューションのパッケージをソースの依存関係で使っているからです。その意味は、それらはディストリビューションとそれのビルドに使われたオプションでパッケージされたLibreOfficeのバージョンを反映している。

Archリナックスなどの他のディストリビューションのさらなる詳細や情報は、 Liunxにおけるビルドの依存関係を見てください。

クローニングとビルド

次にリポジトリを clone して、ビルドを開始します:

$ git clone git://anongit.freedesktop.org/libreoffice/core libreoffice
$ cd libreoffice
$ ./autogen.sh
$ make

make is the command which takes a vast quantity of time to run for the first time. git clone takes a while too.

See notes below for additional options to pass to autogen (e.g. extra debug support).

あなたのビルドを動かす

This will create you a good local installation, which you can then start with:

$ instdir/program/soffice --writer
$ instdir/program/soffice --calc

For starting it directly under a debugger:

$ make debugrun

Then you can open writer with the command:

(gdb) run --writer

Note that soffice.bin will be terminated the first time it is run directly (or via make debugrun), this is normal, you simply need to run it again to make use of it. Running soffice will deal with this for you.

ビデオ チュートリアル

初めてのビルドのビデオチュートリアルl

While this introduction was done on an Ubuntu system, it should work with little modification on any Linux system (see below for details, if needed). We would recommend to watch the video along with performing the steps – it not only walks you through the setup, it also has a excellent soundtrack! ;)

詳細、内部情報、技とヒント

あなたがビルドの最適化やトラブルシューティングの様々な方法を探している時だけここから先を読んでください。
この内部情報はあなたに合うか合わないか分からない荒っぽい見解であることに注意してください。

準備

依存関係

There exists a shell script that download all dependencies and the source code in some Linux distros. It can be find in the github, the name is pre-install.sh: https://github.com/marcosps/lo_useful.git

This page documents how to build the current development version of LibreOffice, based on a git repository named 'core'.

See also Development/Linux Build Dependencies

ディスク容量

At minimum, with the git repositories, and the product built and packaged, you will need 26GB of disk space, depending on the platform, the build options and the specific autogen options you use, a few Gb more if you make a debug build.

If you are working on multiple features at once you can either use git stash or you can setup more than one working directory (we will see later how to set them up). A workdir allow you to have a separate build environment without having to duplicate the git history, but it will still cost you 6 to 9 Gb per workdir.

ソースを手に入れる

In the rest of this tutorial we will work in ~/git. Of course you are free to choose which ever directory you want as a starting point. Now let's download the 'core' git repository:

$ git clone git://anongit.freedesktop.org/libreoffice/core libreoffice
Cloning into libreoffice...
Remote: Counting objects: 76845, done.
remote: Compressing objects: 100% (17328/17328), done.
remote: Total 76845 (delta 60786), reused 74045 (delta 58579)
Receiving objects: 100% (76845/76845), 15.82 MiB | 1.17 MiB/s, done.
Resolving deltas: 100% (60786/60786), done.
$ cd libreoffice

Autogen

Now you need to configure your build. This is done by running a script named 'autogen.sh'. There are many options that can be given to that scripts, please refer to this page describing the options for information.

After you run autogen.sh the first time, you can also get a list of the options by running:

$ ./autogen.sh
[long output]
$ ./autogen.sh --help
'configure' configures LibreOffice 4.0 to adapt to many kinds of systems.

Usage: ./configure [OPTION]... [VAR=VALUE]...

To assign environment variables (e.g., CC, CFLAGS...), specify them as
VAR=VALUE.  See below for descriptions of some of the useful variables.

Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included packages
[....]

Your mileage may vary, depending on your platform and distribution. Here are a few examples:

$ ./autogen.sh --enable-dbgutil --without-java --without-help --without-myspell-dicts # used on linux
$ ./autogen.sh --enable-dbgutil # used on MacOS
$ ./autogen.sh --enable-dbgutil --without-help --without-myspell-dicts # without external repositories (only core)

The --enable-dbgutil option configures for a developer build, disabling optimizations, enabling debugging support and additional checks.

内部情報

ビルドを始める

To run the LibreOffice you have just built, do

$ instdir/program/soffice --writer

When you've re-compiled in any way just re-run from instdir/program.

能力

Building LibreOffice takes time, a lot of time. Exactly how much depends on how powerful your machine is. But there are tools you can use to speed-up things.

ccache

ccache is a tool that caches the results of c/c++ compilation to try to re-use them later. It will not speed-up your initial build (on the contrary it will slow it down a bit), but it can dramatically speed up later re-building. If you plan to change lots of header files in LibreOffice, it is a worthy tool to have.

By default, ccache will be enabled automatically if it is found on your system. For best results, you may want to increase the cache size or enable cache compression; `man ccache` is your friend.

Note that the default cache size is just 1G which is far too small to be useful for a LibreOffice build; for a build without debug symbols, you should have at least 8G cache, and for a build with debug symbols for everything probably 32G is a useful starting point. You can set the size like this (note that this setting is stored inside the cache directory, if you change the location by setting $CCACHE_DIR you have to re-do it):

ccache --max-size 32G

ccache also supports compression, which is very likely a good idea to enable (does anybody have hard numbers?), especially if you are using a small or slow storage medium, like a SSD or laptop hard disk. You can enable compression by adding this to your .bashrc or equivalent:

export CCACHE_COMPRESS=1

distcc / Icecream

If you are in an environment where you have access to multiple machines with spare cpu cycles, you can take a look at distcc or icecream, tools for distributed build.

Support for Icecream is built into LibreOffice, it is enough to add --enable-icecream to ./autogen.sh, and the configure process will pre-set number of jobs to use, and will try to find the icecream gcc wrappers in /opt/icecream/bin. Should you have them somewhere else, please use --with-gcc-home=/path/to/your/icecream/bin switch to override that.

To make use of distcc, first install and start distccd on all the build machines and make sure all the compiler versions are compatible (this is important for C++ code). Now on the driving machine install and configure distcc to use the other build hosts. Then pass --with-parallelism=N to autogen.sh, where N is the total number of CPUs available in your cluster and run distcc-pump make CC=distcc CXX=distcc to start the distributed build.

--with-parallelism

The build process can be told to run multiple tasks in parallel. The parallelism is controlled by the autogen parameter --with-parallelism. If you have enough memory, I found that using --with-parallelism=n where n is your number of cores, or 2 for --with-parallelism if you have only 1 core, give me the fastest build time.

--with-parallelism already defaults to the the number of cores/cpus on your system, unless you use --enable-icecream - then to 10.

--with-system-libs

Building with existing libraries may speed up your build, but you have to fiddle with the dependencies.

概算の時間

An Athlon 435 X3 with ccache without java without epm takes about 1.5 hours for the initial make on gentoo.

The first build, on an Intel 2630QM with ccache without java and epm with --with-parallelism at 8 and ext4 formatted disk takes about 1,5 h too on Kubuntu. The following daily build time varies between 2 and 10 min (depending on the number of modified or added files and their complexity).

詳細な make

Make will hide the exact command invokations. To see what make does exactly for a single run one can invoke it as

$ make GMAKE_OPTIONS='VERBOSE=1'

多重なワークディレクトリ

If you want to work on both the master branch, and the current release branch(es) at the same time, you can share git repos, and external source tarballs (note the savings can be significant, especially if you also use the quite huge l10n repo). Note that switching between different release branches within the same working dir is not recommended; even if there are no dependency problems, the amount of stuff you'd have to rebuild is practically equal to a clean rebuild. If you can afford the diskspace, maintaining separate trees is the recommended way.

There are two methods to share git repos across working directories: git clone --reference and git-new-workdir. A referenced clone can avoid re-downloading the repo, but the new workdir will still have its own .git/config, etc. This is supported by upstream git developers. git-new-workdir, however, is not supported and can cause problems if you try to check out the same branch in two working directories, etc.

設定

Prepare the first build on your disk just like explained above. For the second, and all other builds, do this to clone the initial core repo:

$ git clone --reference /path/to/master --branch name-of-release-branch ssh://logerrit/core /dir/to/be/created

You'll notice a much quicker clone operation. After that, setup the new work dir with these two extra configure (or autogen.sh) options:

$ ./autogen.sh ... --with-referenced-git=/path/to/master --with-external-tar=/path/to/master/external/tarballs

Again, cloning will be much faster. You have to use an absolute path for the --with-external-tar option. After that, you proceed with building just like for the single-workdir case.

The --with-referenced-git option is only needed if you enabled some submodules (translations, dictionaries or help) or you're building the libreoffice-4-0 branch (or one that is even older). On newer branches submodules are disabled by default.

If you want to cherry-pick between the working directories, you can setup your local copy of git to act like a remote, like this:

$ cd /path/to/stable-workingcopy
$ git remote add unstable /path/to/master/.git
$ cd /path/to/master
$ git remote add stable /path/to/stable-workingcopy/.git

You then just cherry-pick commits like you would to a "true" remote on another server.

リリースブランチを調査する

masterはあなたの必要な詳細なパラメータを付けてautogen.sh を実行してください、それから autogen.sh をパスするために必要とされるパラメーターをサブモジュールとして入手するためにmake fetchを実行してください

それから ブランチを切り替えてください

$ ./g checkout -b libreoffice-4-0 origin/libreoffice-4-0

rpm not found/ant not found/no package gnome-vfs-2.0

--disable-epm This will fix "rpm not found", as autogen expects to find either dpkg or rpm on the system.

--without-java This will fix "ant not found"

As of the master towards LibreOffice 3.6, to build the UNO SDK you need to have Doxygen installed so that HTML documentation for the C++ UNO interface can be generated. One option is to install Doxygen from its website and make sure the doxygen executable is found on the PATH, or specify its exact location via --with-doxygen=pathname configure switch. Another option is to configure --without-doxygen, in which case the HTML documentation for the C++ UNO interface will be missing from the UNO SDK being built. A third option is to configure --disable-odk, in which case the UNO SDK is not built at all.

Note: Installing 'libgnomevfs2-dev' package on Ubuntu manually will fix "No package 'gnome-vfs-2.0' found" on older release branches. It should not be needed anymore on master by now. Use synaptic package manager or run in terminal

$ sudo apt-get install libgnomevfs2-dev

DEB 及び/いずれか RPM パッケージのビルド

もしあなたが DEB または RPM パッケージビルドをやりたいのであれば、この技をすべきです...

RPM と DEB
$ ./autogen.sh --with-distro=LibreOfficeLinux --with-package-format="deb rpm" --enable-epm
$ make
RPM
$ ./autogen.sh --with-distro=LibreOfficeLinux --with-package-format=rpm --enable-epm
$ make
DEB
$ ./autogen.sh --with-distro=LibreOfficeLinux --with-package-format=deb --enable-epm
$ make

パッケージはどこにある?

./workdir/installation/ ディレクトリの中のファイルを探してください。各々が異なるDEB、RPMのいずれか、又は両方のタイプのパッケージのセットのフォルダーがあります。内部ではサブフォルダーはinstallと呼ばれる異なるフォルダーです、そしてそれは2つのサブフォルダーを含んでいます。ひとつのサブフォルダーは(..._ダウンロードフォルダー)全体を圧縮したパッケージの全ての保存記録を含んでいます、そして他のフォルダーはそれぞれの個別のDEBS/RPMSフォルダーを含んでいます。後は説明不要ですね!

ラインの終了と Git's autocrlf に取り組む

If autogen.sh produces output like the following:

./autogen.sh: line 1: $':\r': command not found
' '--srcdir=/home/user/libreoffice' '--enable-option-checking=fatal'
configure: WARNING: you should use --build, --host, --target
configure: WARNING: invalid host type:
********************************************************************
*
*   Running LibreOffice build configuration.
*
********************************************************************

' not recognizedystem type... Invalid configuration `
 failedre: error: /bin/bash ./config.sub
Error running configure at ./autogen.sh line 241.

... then you probably have line ending problems. This might occur if you mistakenly set Git's core.autocrlf=true.

To fix the issue, run these commands (WARNING: uncommitted changes will be lost!):

git config --unset core.autocrlf
git rm --cached -r .
git reset --hard
git clean -x -f
./autogen.sh