Difference between revisions of "CompilingAutopackage"
m |
|||
Line 5: | Line 5: | ||
* You may need to tweak the specfile (packaging/autopackage/default.apspec.in) to fit your own needs. eg. add your name as the packager. :) | * You may need to tweak the specfile (packaging/autopackage/default.apspec.in) to fit your own needs. eg. add your name as the packager. :) | ||
* Collect static (*.a) versions of gtkmm, libgc and libpopt. It should be possible to obtain these libraries by installing the appropriate dev or devel packages for your distro. | * Collect static (*.a) versions of gtkmm, libgc and libpopt. It should be possible to obtain these libraries by installing the appropriate dev or devel packages for your distro. | ||
* It might be best to built your own static copy of libgc (the [http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Boehm Garbage Collector]) to ensure it was built with C | * It might be best to built your own static copy of libgc (the [http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Boehm Garbage Collector]) to ensure it was built with C++ support and to increase binary portability by using apbuild (included with the autopackage developer tools). | ||
**export CC=apgcc | **export CC=apgcc | ||
**export CXX=apg | **export CXX=apg++ | ||
**./configure --enable-cplusplus | **./configure --enable-cplusplus | ||
**make | **make | ||
Line 14: | Line 14: | ||
* Currently gtkspell must be disabled in configure.ac as below (this is a temporary fix that will be corrected in later versions) | * Currently gtkspell must be disabled in configure.ac as below (this is a temporary fix that will be corrected in later versions) | ||
-if pkg-conf --exists gtkspell-2.0; then | -if pkg-conf --exists gtkspell-2.0; then | ||
+if false && pkg-conf --exists gtkspell-2.0; then | |||
* ./autogen.sh && ./configure && make clean | |||
* makeinstaller packaging/autopackage/default.apspec | |||
=== Recompiles === | |||
* You can skip configure and make for recompiles with: | |||
makeinstaller -c -m packaging/autopackage/default.apspec | |||
=== Known issues === | |||
If you see crashes almost immediately on startup, you're seeing GCC bug 21405. This is triggered by having '''any''' C++ library from the users system linked into the running process image, even if it's not linked to directly. | |||
A common problem is that GTKmm isn't being statically linked. The solution is to ensure you are statically linking GTKmm correctly (and any other C++ libraries that may be needed). You can see what libraries are dynamically linked to the binary by running | |||
objdump -x inkscape | grep NEEDED | |||
If there are any C++ libraries in that list, statically link them. | |||
=== Future work === | |||
Autopackage 1.2 will include a new type of C++ support based on binary deltas. By ensuring the user always has a binary of the right ABI for their system, it becomes safe to use system-installed C++ libraries again. This opens up the following possibilities: | |||
* Not statically linking GTKmm, but rather using the autopackage depsolver. It might be more convenient to continue with the current approach though. | |||
* dlopening/relaytooling GTKspell. This isn't safe currently, because libaspell is written in C++, so we hit GCC bug 21405 again. | |||
Other work involves: | |||
* Ensuring it's built with the latest autopackage version | |||
* Migrating it to autopackage 1.2 when it comes out later this year | |||
* Weak linking more dependencies, such as: | |||
** GTKspell | |||
** GNOME-VFS | |||
** Any others? | |||
[[Category:Developer Documentation]] |
Revision as of 15:50, 20 April 2007
Autopackage is a set of tools for building low overhead, distribution-neutral packages, distributing them, and installing using with a variety of front-ends. Visit http://autopackage.org to learn more.
Prerequisites
- Download and install the Autopackage developer tools from http://autopackage.org/download-tools.html
- You may need to tweak the specfile (packaging/autopackage/default.apspec.in) to fit your own needs. eg. add your name as the packager. :)
- Collect static (*.a) versions of gtkmm, libgc and libpopt. It should be possible to obtain these libraries by installing the appropriate dev or devel packages for your distro.
- It might be best to built your own static copy of libgc (the Boehm Garbage Collector) to ensure it was built with C++ support and to increase binary portability by using apbuild (included with the autopackage developer tools).
- export CC=apgcc
- export CXX=apg++
- ./configure --enable-cplusplus
- make
Compile
- ./autogen.sh
- Currently gtkspell must be disabled in configure.ac as below (this is a temporary fix that will be corrected in later versions)
-if pkg-conf --exists gtkspell-2.0; then +if false && pkg-conf --exists gtkspell-2.0; then
- ./autogen.sh && ./configure && make clean
- makeinstaller packaging/autopackage/default.apspec
Recompiles
- You can skip configure and make for recompiles with:
makeinstaller -c -m packaging/autopackage/default.apspec
Known issues
If you see crashes almost immediately on startup, you're seeing GCC bug 21405. This is triggered by having any C++ library from the users system linked into the running process image, even if it's not linked to directly.
A common problem is that GTKmm isn't being statically linked. The solution is to ensure you are statically linking GTKmm correctly (and any other C++ libraries that may be needed). You can see what libraries are dynamically linked to the binary by running
objdump -x inkscape | grep NEEDED
If there are any C++ libraries in that list, statically link them.
Future work
Autopackage 1.2 will include a new type of C++ support based on binary deltas. By ensuring the user always has a binary of the right ABI for their system, it becomes safe to use system-installed C++ libraries again. This opens up the following possibilities:
- Not statically linking GTKmm, but rather using the autopackage depsolver. It might be more convenient to continue with the current approach though.
- dlopening/relaytooling GTKspell. This isn't safe currently, because libaspell is written in C++, so we hit GCC bug 21405 again.
Other work involves:
- Ensuring it's built with the latest autopackage version
- Migrating it to autopackage 1.2 when it comes out later this year
- Weak linking more dependencies, such as:
- GTKspell
- GNOME-VFS
- Any others?