yann@2076
|
1 |
File.........: C - Misc. tutorials.txt
|
yann@2076
|
2 |
Copyrigth....: (C) 2010 Yann E. MORIN <yann.morin.1998@anciens.enib.fr>
|
yann@2076
|
3 |
License......: Creative Commons Attribution Share Alike (CC-by-sa), v2.5
|
yann@2076
|
4 |
|
yann@2076
|
5 |
|
yann@2076
|
6 |
Misc. tutorials /
|
yann@2076
|
7 |
________________/
|
yann@2076
|
8 |
|
yann@2076
|
9 |
|
yann@2076
|
10 |
Using crosstool-NG on FreeBSD (and other *BSD) |
|
yann@2076
|
11 |
-----------------------------------------------+
|
yann@2076
|
12 |
|
yann@2076
|
13 |
Contributed by: Titus von Boxberg
|
yann@2076
|
14 |
|
yann@2076
|
15 |
Prerequisites and instructions for using ct-ng for building a cross toolchain on FreeBSD as host.
|
yann@2076
|
16 |
|
yann@2076
|
17 |
0) Tested on FreeBSD 8.0
|
yann@2076
|
18 |
|
yann@2076
|
19 |
1) Install (at least) the following ports
|
yann@2076
|
20 |
archivers/lzma
|
yann@2076
|
21 |
textproc/gsed
|
yann@2076
|
22 |
devel/gmake
|
yann@2076
|
23 |
devel/patch
|
yann@2076
|
24 |
shells/bash
|
yann@2076
|
25 |
devel/bison
|
yann@2076
|
26 |
lang/gawk
|
yann@2076
|
27 |
devel/automake110
|
yann@2076
|
28 |
ftp/wget
|
yann@2076
|
29 |
|
yann@2076
|
30 |
Of course, you should have /usr/local/bin in your PATH.
|
yann@2076
|
31 |
|
yann@2076
|
32 |
2) run ct-ng's configure with the following tool configuration:
|
yann@2076
|
33 |
./configure --with-sed=/usr/local/bin/gsed --with-make=/usr/local/bin/gmake \
|
yann@2076
|
34 |
--with-patch=/usr/local/bin/gpatch
|
yann@2076
|
35 |
[...other configure parameters as you like...]
|
yann@2076
|
36 |
|
yann@2076
|
37 |
3) proceed as described in general documentation
|
yann@2076
|
38 |
but use gmake instead of make
|
yann@2076
|
39 |
|
yann@2076
|
40 |
|
yann@2076
|
41 |
Using crosstool-NG on MacOS-X |
|
yann@2076
|
42 |
------------------------------+
|
yann@2076
|
43 |
|
yann@2076
|
44 |
Contributed by: Titus von Boxberg
|
yann@2076
|
45 |
|
yann@2076
|
46 |
Prerequisites and instructions for using crosstool-NG for building a cross
|
yann@2076
|
47 |
toolchain on MacOS as host.
|
yann@2076
|
48 |
|
yann@2076
|
49 |
0) Mac OS Snow Leopard, with Developer Tools 3.2 installed, or
|
yann@2076
|
50 |
Mac OS Leopard, with Developer Tools & newer gcc (>= 4.3) installed
|
yann@2076
|
51 |
via macports
|
yann@2076
|
52 |
|
yann@2076
|
53 |
1) You have to use a case sensitive file system for ct-ng's build and target
|
yann@2076
|
54 |
directories. Use a disk or disk image with a case sensitive fs that you
|
yann@2076
|
55 |
mount somewhere.
|
yann@2076
|
56 |
|
yann@2076
|
57 |
2) Install macports (or similar easy means of installing 3rd party software),
|
yann@2076
|
58 |
make sure that macport's bin dir is in your PATH.
|
yann@2076
|
59 |
Furtheron assuming it is /opt/local/bin.
|
yann@2076
|
60 |
|
yann@2076
|
61 |
3) Install (at least) the following macports
|
yann@2076
|
62 |
ncurses
|
yann@2076
|
63 |
lzmautils
|
yann@2076
|
64 |
libtool
|
yann@2076
|
65 |
binutils
|
yann@2076
|
66 |
gsed
|
yann@2076
|
67 |
gawk
|
yann@2076
|
68 |
gcc43 (only necessary for Leopard OSX 10.5)
|
yann@2076
|
69 |
|
yann@2076
|
70 |
On Leopard, make sure that the macport's gcc is called with the default
|
yann@2076
|
71 |
commands (gcc, g++,...), e.g. via macport gcc_select
|
yann@2076
|
72 |
|
yann@2076
|
73 |
4) run ct-ng's configure with the following tool configuration
|
yann@2076
|
74 |
(assuming you have installed the tools via macports in /opt/local):
|
yann@2076
|
75 |
./configure --with-sed=/opt/local/bin/gsed \
|
yann@2076
|
76 |
--with-libtool=/opt/local/bin/glibtool \
|
yann@2076
|
77 |
--with-objcopy=/opt/local/bin/gobjcopy \
|
yann@2076
|
78 |
--with-objdump=/opt/local/bin/gobjdump \
|
yann@2076
|
79 |
--with-readelf=/opt/local/bin/greadelf \
|
yann@2076
|
80 |
[...other configure parameters as you like...]
|
yann@2076
|
81 |
|
yann@2076
|
82 |
5) proceed as described in standard documentation
|
yann@2076
|
83 |
|
yann@2076
|
84 |
-----
|
yann@2076
|
85 |
|
yann@2076
|
86 |
HINTS:
|
yann@2076
|
87 |
- Apparently, GNU make's builtin variable .LIBPATTERNS is misconfigured
|
yann@2076
|
88 |
under MacOS: It does not include lib%.dylib.
|
yann@2076
|
89 |
This affects build of (at least) gdb-7.1
|
yann@2076
|
90 |
Put 'lib%.a lib%.so lib%.dylib' as .LIBPATTERNS into your environment
|
yann@2076
|
91 |
before executing ct-ng build.
|
yann@2076
|
92 |
See http://www.gnu.org/software/make/manual/html_node/Libraries_002fSearch.html
|
yann@2076
|
93 |
as an explanation.
|
yann@2077
|
94 |
|
yann@2077
|
95 |
|
yann@2077
|
96 |
Using Mercurial to hack crosstool-NG |
|
yann@2077
|
97 |
-------------------------------------+
|
yann@2077
|
98 |
|
yann@2077
|
99 |
Contributed by: Titus von Boxberg
|
yann@2077
|
100 |
|
yann@2077
|
101 |
PREREQUISITES:
|
yann@2077
|
102 |
|
yann@2077
|
103 |
Configuring Mercurial:
|
yann@2077
|
104 |
You need mercurial with the following extensions:
|
yann@2077
|
105 |
- mq : http://mercurial.selenic.com/wiki/MqExtension
|
yann@2077
|
106 |
- patchbomb : http://mercurial.selenic.com/wiki/PatchbombExtension
|
yann@2077
|
107 |
Usually, these two extensions are already part of the installation package.
|
yann@2077
|
108 |
The mq extension maintains a separate queue of your local changes
|
yann@2077
|
109 |
that you can change at any later time.
|
yann@2077
|
110 |
With the patchbomb extension you can email those patches directly
|
yann@2077
|
111 |
from your local repo.
|
yann@2077
|
112 |
|
yann@2077
|
113 |
Your configuration file for mercurial, e.g. ~/.hgrc should contain
|
yann@2077
|
114 |
at least the following sections (but have a look at `man hgrc`):
|
yann@2077
|
115 |
# ---
|
yann@2077
|
116 |
[email]
|
yann@2077
|
117 |
# configure sending patches directly via Mercurial
|
yann@2077
|
118 |
from = "Your Name" <your@email.address>
|
yann@2077
|
119 |
# How to send email:
|
yann@2077
|
120 |
method = smtp
|
yann@2077
|
121 |
|
yann@2077
|
122 |
[smtp]
|
yann@2077
|
123 |
# SMTP configuration (only for method=smtp)
|
yann@2077
|
124 |
host = localhost
|
yann@2077
|
125 |
tls = true
|
yann@2077
|
126 |
username =
|
yann@2077
|
127 |
password =
|
yann@2077
|
128 |
|
yann@2077
|
129 |
[extensions]
|
yann@2077
|
130 |
# The following lines enable the two extensions:
|
yann@2077
|
131 |
hgext.mq =
|
yann@2077
|
132 |
hgext.patchbomb =
|
yann@2077
|
133 |
# ----
|
yann@2077
|
134 |
|
yann@2077
|
135 |
Create your local repository as a clone:
|
yann@2077
|
136 |
hg clone http://ymorin.is-a-geek.org/hg/crosstool-ng crosstool-ng
|
yann@2077
|
137 |
|
yann@2077
|
138 |
Setting up the mq extension in your local copy:
|
yann@2077
|
139 |
cd crosstool-ng
|
yann@2077
|
140 |
hg qinit
|
yann@2077
|
141 |
|
yann@2077
|
142 |
|
yann@2077
|
143 |
CREATING PATCHES:
|
yann@2077
|
144 |
|
yann@2077
|
145 |
Recording your changes in the patch queue maintained by mq:
|
yann@2077
|
146 |
# First, create a new patch entry in the patch queue:
|
yann@2077
|
147 |
hg qnew -D -U -e short_patch_name1
|
yann@2077
|
148 |
<edit patch description as commit message (see below for an example)>
|
yann@2077
|
149 |
|
yann@2077
|
150 |
<now edit the ct-ng sources and check them>
|
yann@2077
|
151 |
|
yann@2077
|
152 |
# if you execute `hg status` here, your modifications of the working
|
yann@2077
|
153 |
# copy should show up.
|
yann@2077
|
154 |
|
yann@2077
|
155 |
# Now the following command takes your modifications from the working copy
|
yann@2077
|
156 |
# into the patch entry
|
yann@2077
|
157 |
hg qrefresh -D [-e]
|
yann@2077
|
158 |
<reedit patch description [-e] if desired>
|
yann@2077
|
159 |
|
yann@2077
|
160 |
# Now your changes are recorded, and `hg status` should show a clean
|
yann@2077
|
161 |
# working copy
|
yann@2077
|
162 |
|
yann@2077
|
163 |
Repeat the above steps for all your modifications.
|
yann@2077
|
164 |
The command `hg qseries` informs you about the content of your patch queue.
|
yann@2077
|
165 |
|
yann@2077
|
166 |
|
yann@2077
|
167 |
CONTRIBUTING YOUR PATCHES:
|
yann@2077
|
168 |
|
yann@2077
|
169 |
Once you are satisfied with your patch series, you can (you should!)
|
yann@2077
|
170 |
contribute them back to upstream.
|
yann@2077
|
171 |
This is easily done using the `hg email` command.
|
yann@2077
|
172 |
|
yann@2077
|
173 |
`hg email` sends your new changesets to a specified list of recipients,
|
yann@2077
|
174 |
each patch in its own email, all ordered in the way you entered them (oldest
|
yann@2077
|
175 |
first). The command line flag --outgoing selects all changesets that are in
|
yann@2077
|
176 |
your local but not yet in the upstream repository. Here, these are exactly
|
yann@2077
|
177 |
the ones you entered into your local patch queue in the section above, so
|
yann@2077
|
178 |
--outgoing is what you want.
|
yann@2077
|
179 |
|
yann@2077
|
180 |
Each email gets the subject set to: "[PATCH x of n] <series summary>"
|
yann@2077
|
181 |
where 'x' is the serial number in the email series, and 'n' is the total number
|
yann@2077
|
182 |
of patches in the series. The body of the email is the complete patch, plus
|
yann@2077
|
183 |
a handful of metadata, that helps properly apply the patch, keeping the log
|
yann@2077
|
184 |
message, attribution and date, tracking file changes (move, delete, modes...)
|
yann@2077
|
185 |
|
yann@2077
|
186 |
`hg email` also threads all outgoing patch emails below an introductory
|
yann@2077
|
187 |
message. You should use the introductory message (command line flag --intro)
|
yann@2077
|
188 |
to describe the scope and motivation for the whole patch series. The subject
|
yann@2077
|
189 |
for the introductory message gets set to: "[PATCH 0 of n] <series summary>"
|
yann@2077
|
190 |
and you get the chance to set the <series summary>.
|
yann@2077
|
191 |
|
yann@2077
|
192 |
Here is a sample `hg email` complete command line:
|
yann@2077
|
193 |
Note: replace " (at) " with "@"
|
yann@2077
|
194 |
|
yann@2077
|
195 |
hg email --outgoing --intro \
|
yann@2077
|
196 |
--to '"Yann E. MORIN" <yann.morin.1998 (at) anciens.enib.fr>' \
|
yann@2077
|
197 |
--cc 'crossgcc (at) sourceware.org'
|
yann@2077
|
198 |
|
yann@2077
|
199 |
# It then opens an editor and lets you enter the subject
|
yann@2077
|
200 |
# and the body for the introductory message.
|
yann@2077
|
201 |
|
yann@2077
|
202 |
Use `hg email` with the additional command line switch -n to
|
yann@2077
|
203 |
first have a look at the email(s) without actually sending them.
|
yann@2077
|
204 |
|
yann@2077
|
205 |
|
yann@2077
|
206 |
MAINTAINING YOUR PATCHES:
|
yann@2077
|
207 |
|
yann@2077
|
208 |
When the patches are refined by discussing them on the mailing list,
|
yann@2077
|
209 |
you may want to finalize and resend them.
|
yann@2077
|
210 |
|
yann@2077
|
211 |
The mq extension has the idiosyncrasy of imposing a stack onto the queue:
|
yann@2077
|
212 |
You can always reedit/refresh only the patch on top of stack.
|
yann@2077
|
213 |
The queue consists of applied and unapplied patches
|
yann@2077
|
214 |
(if you reached here via the above steps, all of your patches are applied),
|
yann@2077
|
215 |
where the 'stack' consists of the applied patches, and 'top of stack'
|
yann@2077
|
216 |
is the latest applied patch.
|
yann@2077
|
217 |
|
yann@2077
|
218 |
The following output of `hg qseries` is now used as an example:
|
yann@2077
|
219 |
0 A short_patch_name1
|
yann@2077
|
220 |
1 A short_patch_name2
|
yann@2077
|
221 |
2 A short_patch_name3
|
yann@2077
|
222 |
3 A short_patch_name4
|
yann@2077
|
223 |
|
yann@2077
|
224 |
You are now able to edit patch 'short_patch_name4' (which is top of stack):
|
yann@2077
|
225 |
<Edit the sources>
|
yann@2077
|
226 |
# and execute again
|
yann@2077
|
227 |
hg qrefresh -D [-e]
|
yann@2077
|
228 |
<and optionally [-e] reedit the commit message>
|
yann@2077
|
229 |
|
yann@2077
|
230 |
If you want to edit e.g. patch short_patch_name2, you have to modify
|
yann@2077
|
231 |
mq's stack so this patch gets top of stack.
|
yann@2077
|
232 |
For this purpose see `hg help qgoto`, `hg help qpop`, and `hg help qpush`.
|
yann@2077
|
233 |
|
yann@2077
|
234 |
hg qgoto short_patch_name2
|
yann@2077
|
235 |
# The patch queue should now look like
|
yann@2077
|
236 |
hg qseries
|
yann@2077
|
237 |
0 A short_patch_name1
|
yann@2077
|
238 |
1 A short_patch_name2
|
yann@2077
|
239 |
2 U short_patch_name3
|
yann@2077
|
240 |
3 U short_patch_name4
|
yann@2077
|
241 |
# so patch # 1 (short_patch_name2) is top of stack.
|
yann@2077
|
242 |
<now reedit the sources for short_patch_name2>
|
yann@2077
|
243 |
# and execute again
|
yann@2077
|
244 |
hg qrefresh -D [-e]
|
yann@2077
|
245 |
<and optionally [-e] reedit the commit message>
|
yann@2077
|
246 |
# the following command reapplies the now unapplied two patches:
|
yann@2077
|
247 |
hg qpush -a
|
yann@2077
|
248 |
# you can also use `hg qgoto short_patch_name4` to get there again.
|
yann@2077
|
249 |
|
yann@2077
|
250 |
|
yann@2077
|
251 |
RESENDING YOUR REEDITED PATCHES:
|
yann@2077
|
252 |
|
yann@2077
|
253 |
By mailing list policy, please resend your complete patch series.
|
yann@2077
|
254 |
--> Go back to section "CONTRIBUTING YOUR PATCHES" and resubmit the full set.
|
yann@2077
|
255 |
|
yann@2077
|
256 |
|
yann@2077
|
257 |
SYNCING WITH UPSTREAM AGAIN:
|
yann@2077
|
258 |
|
yann@2077
|
259 |
You can sync your repo with upstream at any time by executing
|
yann@2077
|
260 |
# first unapply all your patches:
|
yann@2077
|
261 |
hg qpop -a
|
yann@2077
|
262 |
# next fetch new changesets from upstream
|
yann@2077
|
263 |
hg pull
|
yann@2077
|
264 |
# then update your working copy
|
yann@2077
|
265 |
hg up
|
yann@2077
|
266 |
# optionally remove already upstream integrated patches (see below)
|
yann@2077
|
267 |
hg qdelete <short_name_of_already_applied_patch>
|
yann@2077
|
268 |
# and reapply your patches if any non upstream-integrated left (but see below)
|
yann@2077
|
269 |
hg qpush -a
|
yann@2077
|
270 |
|
yann@2077
|
271 |
Eventually, your patches get included into the upstream repository
|
yann@2077
|
272 |
which you initially cloned.
|
yann@2077
|
273 |
In this case, before executing the hg qpush -a from above
|
yann@2077
|
274 |
you should manually "hg qdelete" the patches that are already integrated upstream.
|
yann@2077
|
275 |
|
yann@2077
|
276 |
|
yann@2077
|
277 |
HOW TO FORMAT COMMIT MESSAGES (aka patch desciptions):
|
yann@2077
|
278 |
|
yann@2077
|
279 |
Commit messages should look like (without leading pipes):
|
yann@2077
|
280 |
|component: short, one-line description
|
yann@2077
|
281 |
|
|
yann@2077
|
282 |
|optional longer description
|
yann@2077
|
283 |
|on multiple lines if needed
|
yann@2077
|
284 |
|
yann@2077
|
285 |
Here is an example commit message (see revision a53a5e1d61db):
|
yann@2077
|
286 |
|comp-libs/cloog: fix building
|
yann@2077
|
287 |
|
|
yann@2077
|
288 |
|For CLooG/PPL 0.15.3, the directory name was simply cloog-ppl.
|
yann@2077
|
289 |
|For any later versions, the directory name does have the version, such as
|
yann@2077
|
290 |
|cloog-ppl-0.15.4.
|