1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
|
Instructions on how to build a bundle for 64bit linux systems.
System requirements
~~~~~~~~~~~~~~~~~~~
o A 64bit linux system
o AppImageKit (https://github.com/probonopd/AppImageKit)
To build AppImageKit, you will require:
- A functional cross compiler to generate 32bit binaries as well as 64bit binaries
- libfuse (if AppImageKit doesnt find it, make sure there is a symbolic link to libfuse.so
from it's actual library, this is because AppImageKit uses CMake, and CMake itself
is just not smart).
- An old glib version installed on your system, the older the glib version the better
(this system glib version will be required on target hosts which want to run the bundle).
- Some other things like python, which you will just have to deal with the CMakeLists.txt
to figure out.
o jhbuild
The bundler mechanism for Glade comes in the form of a jhbuild scripted environment, you will
need a relatively new checkout of jhbuild.
o chrpath
This will be required after your build root is complete, we use it to strip out the -rpaths which
libtool loves to embed into binaries.
o Vala compiler, we'll be using valac --pkg gee-0.8 --pkg posix --pkg glib-2.0 --pkg gio-2.0
Build Instructions
~~~~~~~~~~~~~~~~~~
Make sure you have Glade sources *first*.
We will refer to your Glade checkout or tarball directory as ${GLADE_CHECKOUT}, we expect
this to be a "/full/path/to/the/checkout/of/glade"
Build the LibcWrapGenerator
~~~~~~~~~~~~~~~~~~~~~~~~~~~
To update the libcwrap.h for your system's version of glibc, first you must build
the LibcWrapGenerator like so:
cd ${GLADE_CHECKOUT}/build/linux
valac --pkg gee-0.8 --pkg posix --pkg glib-2.0 --pkg gio-2.0 LibcWrapGenerator.vala
Note that the environment in which you choose to build and run the generator is of
absolutely no consequence, I had to build & run this from an existing jhbuild environment
because I lacked the gee-0.8, this is absolutely not a problem.
Updating libcwrap.h
~~~~~~~~~~~~~~~~~~~
The libcwrap.h header file is the magick which ensures that you target a specific
version of the glibc ABI.
To generate the libcwrap.h file, run the generator like so:
cd ${GLADE_CHECKOUT}/build/linux
./LibcWrapGenerator libcwrap.h 2.7 /path/to/libc/runtime/libraries
We recommend using 2.7 as a stable base glibc requirement, the patches
for this bundle (which are only a few) allow usage of glibc 2.7 and later.
The path to your libc runtime should be a directory containing libc.so.6
and other libc runtime libraries, some systems keep this in different
directories (i.e. /lib/x86_64-linux-gnu, /lib, /lib64 are good bets).
For a more detailed explanation of what libcwrap.h does, look into the
file header of LibcWrapGenerator.vala.
Building AppImageKit
~~~~~~~~~~~~~~~~~~~~
Fetch AppImageKit form https://github.com/probonopd/AppImageKit/
To build follow these steps:
cd AppImageKit
export CC='gcc -U_FORTIFY_SOURCE -include ${GLADE_CHECKOUT}/build/linux/libcwrap.h'
cmake .
make
unset CC
Building the stack
~~~~~~~~~~~~~~~~~~
To build the whole stack up to Glade, including Glade, issue this command:
BUNDLE_ROOT=~/GladeBundle BUNDLE_DIR=${GLADE_CHECKOUT}/build/linux jhbuild -f ${GLADE_CHECKOUT}/build/linux/jhbuildrc build
This will build everything into the ${BUNDLE_ROOT} you specified, the actual installation
will be found in ${BUNDLE_ROOT}/Install
This will not interfere with any existing jhbuild environment you may already have setup,
everything is self contained and happens inside the ${BUNDLE_ROOT} you specify.
Post processing the image directory
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Some post processing is needed on the AppDir, we intentionally keep this separate from
the jhbuild setup. To perform the needed post processing, issue this command:
${GLADE_CHECKOUT}/build/linux/PrepareAppDir.sh ${BUNDLE_ROOT}/Install ${GLADE_CHECKOUT}/build/linux
WARNING: The above script will modify the ${BUNDLE_ROOT}/Install directory in such
a way that it cannot be rebuilt (development headers and unneeded cruft is removed
from the installation directory). This is why we use a script as a separate stage from
building.
At this point, you should have a fully functional image in ${BUNDLE_ROOT}/Install
Bundling
~~~~~~~~
Build the bundle with one simple command:
/path/to/AppImageKit/AppImageAssistant ${BUNDLE_ROOT}/Install ~/glade
This will create a huge binary named 'glade' at the location of your choosing.
Running and Debugging the bundle
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You can run the created bundle by simply executing it, hopefully
this will work on a large variety of 64-bit linux systems.
If things turn out badly, you can debug it by typing:
APP_IMAGE_TEST=1 ./glade
Instead of running glade, this will give you a shell inside
the mounted bundle environment.
Some checks you may want to perform include:
ldd bin/glade
This should show you which libraries are linked to the system
and which are properly pulled from the bundle. We've intentionally
left out X11 libraries, fontconfig and freetype, so these should
be pulled from somewhere in your system directories.
LD_DEBUG=all ./bin/glade > ${HOME}/bindings.log 2>&1
This will create a log of all the symbol bindings, you may want
to check here if any symbol originating in the bundle is bound
to GLIBC > 2.7, the intention with this configuration is to aim
for a low glibc dependency, if libraries inside your bundle require
a higher libc version than 2.7 then the libcwrap.h file probably
needs to be regenerated (the committed version should work for
glibc ABI versions up to 2.15).
Note that as we rely on the system's Xlib libraries, fontconfig
and freetype libraries, there will be references to GLIBC > 2.7
from those system libraries, this is not a problem at all as they
will be resolved differently on hosts with older glibc.
|
