CompilingAutopackage - Revision history

Mgmax: removed - outdated

2019-05-28T14:43:14Z

removed - outdated

← Older revision		Revision as of 14:43, 28 May 2019
Line 1:		Line 1:
	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 [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 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?

	~~[[Category:Developer Documentation]]~~

Colin Marquardt: Reverted edits by Ns9Dje (Talk); changed back to last version by GigaClon

2007-04-20T15:50:13Z

Reverted edits by Ns9Dje (Talk); changed back to last version by GigaClon

← Older revision		Revision as of 15:50, 20 April 2007
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 support and to increase binary portability by using apbuild (included with the autopackage developer tools).		* 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		+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]]

Ns9Dje at 12:40, 12 April 2007

2007-04-12T12:40:52Z

← Older revision		Revision as of 12:40, 12 April 2007
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++ support and to increase binary portability by using apbuild (included with the autopackage developer tools).		* 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~~		if false
	* ./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]]~~

GigaClon: Categorization

2006-06-21T16:18:38Z

Categorization

New page

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 [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 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?

[[Category:Developer Documentation]]