-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy pathCross-compilation.html
555 lines (513 loc) · 24.9 KB
/
Cross-compilation.html
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
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
<!DOCTYPE html>
<html lang="en">
<head>
<base href=".">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Cross compilation</title>
<link rel="stylesheet" href="assets/css/dark-frontend.css" type="text/css" title="dark">
<link rel="alternate stylesheet" href="assets/css/light-frontend.css" type="text/css" title="light">
<link rel="stylesheet" href="assets/css/bootstrap-toc.min.css" type="text/css">
<link rel="stylesheet" href="assets/css/jquery.mCustomScrollbar.min.css">
<link rel="stylesheet" href="assets/js/search/enable_search.css" type="text/css">
<link rel="stylesheet" href="assets/css/notes.css" type="text/css">
<link rel="stylesheet" href="assets/css/prism-tomorrow.css" type="text/css" title="dark">
<link rel="alternate stylesheet" href="assets/css/prism.css" type="text/css" title="light">
<script src="assets/js/mustache.min.js"></script>
<script src="assets/js/jquery.js"></script>
<script src="assets/js/bootstrap.js"></script>
<script src="assets/js/scrollspy.js"></script>
<script src="assets/js/typeahead.jquery.min.js"></script>
<script src="assets/js/search.js"></script>
<script src="assets/js/compare-versions.js"></script>
<script src="assets/js/jquery.mCustomScrollbar.concat.min.js"></script>
<script src="assets/js/bootstrap-toc.min.js"></script>
<script src="assets/js/jquery.touchSwipe.min.js"></script>
<script src="assets/js/anchor.min.js"></script>
<script src="assets/js/tag_filtering.js"></script>
<script src="assets/js/language_switching.js"></script>
<script src="assets/js/styleswitcher.js"></script>
<script src="assets/js/lines_around_headings.js"></script>
<script src="assets/js/prism-core.js"></script>
<script src="assets/js/prism-autoloader.js"></script>
<script src="assets/js/prism_autoloader_path_override.js"></script>
<script src="assets/js/prism-keep-markup.js"></script>
<script src="assets/js/trie.js"></script>
<link rel="icon" type="image/png" href="assets/images/favicon.png">
<link rel="shortcut icon" href="assets/images/favicon.png">
</head>
<body class="no-script
">
<script>
$('body').removeClass('no-script');
</script>
<nav class="navbar navbar-fixed-top navbar-default" id="topnav">
<div class="container-fluid">
<div class="navbar-right">
<a id="toc-toggle">
<span class="glyphicon glyphicon-menu-right"></span>
<span class="glyphicon glyphicon-menu-left"></span>
</a>
<button type="button" class="navbar-toggle collapsed" data-toggle="collapse" data-target="#navbar-wrapper" aria-expanded="false">
<span class="sr-only">Toggle navigation</span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
<span class="icon-bar"></span>
</button>
<span title="light mode switch" class="glyphicon glyphicon-sunglasses pull-right" id="lightmode-icon"></span>
<form class="navbar-form pull-right" id="navbar-search-form">
<div class="form-group has-feedback">
<input type="text" class="form-control input-sm" name="search" id="sidenav-lookup-field" placeholder="search" disabled>
<span class="glyphicon glyphicon-search form-control-feedback" id="search-mgn-glass"></span>
</div>
</form>
</div>
<div class="navbar-header">
<a id="sidenav-toggle">
<span class="glyphicon glyphicon-menu-right"></span>
<span class="glyphicon glyphicon-menu-left"></span>
</a>
<a id="home-link" href="index.html" class="hotdoc-navbar-brand">
<img src="assets/images/meson_logo.png" alt="Home">
</a>
</div>
<div class="navbar-collapse collapse" id="navbar-wrapper">
<ul class="nav navbar-nav" id="menu">
<li class="dropdown">
<a class="dropdown-toggle" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
Modules <span class="caret"></span>
</a>
<ul class="dropdown-menu" id="modules-menu">
<li>
<a href="CMake-module.html">CMake</a>
</li>
<li>
<a href="Cuda-module.html">CUDA</a>
</li>
<li>
<a href="Dlang-module.html">Dlang</a>
</li>
<li>
<a href="External-Project-module.html">External Project</a>
</li>
<li>
<a href="Fs-module.html">Filesystem</a>
</li>
<li>
<a href="Gnome-module.html">GNOME</a>
</li>
<li>
<a href="Hotdoc-module.html">Hotdoc</a>
</li>
<li>
<a href="i18n-module.html">i18n</a>
</li>
<li>
<a href="Icestorm-module.html">Icestorm</a>
</li>
<li>
<a href="Java-module.html">Java</a>
</li>
<li>
<a href="Keyval-module.html">Keyval</a>
</li>
<li>
<a href="Pkgconfig-module.html">Pkgconfig</a>
</li>
<li>
<a href="Python-3-module.html">Python 3</a>
</li>
<li>
<a href="Python-module.html">Python</a>
</li>
<li>
<a href="Qt4-module.html">Qt4</a>
</li>
<li>
<a href="Qt5-module.html">Qt5</a>
</li>
<li>
<a href="Qt6-module.html">Qt6</a>
</li>
<li>
<a href="Rust-module.html">Rust</a>
</li>
<li>
<a href="Simd-module.html">Simd</a>
</li>
<li>
<a href="SourceSet-module.html">SourceSet</a>
</li>
<li>
<a href="Wayland-module.html">Wayland</a>
</li>
<li>
<a href="Windows-module.html">Windows</a>
</li>
</ul>
</li>
<li class="dropdown">
<a class="dropdown-toggle" role="button" data-toggle="dropdown" aria-haspopup="true" aria-expanded="false">
Quick References <span class="caret"></span>
</a>
<ul class="dropdown-menu" id="quick-refs-menu">
<li>
<a href="Reference-manual.html">Functions</a>
</li>
<li>
<a href="Build-options.html">Options</a>
</li>
<li>
<a href="Configuration.html">Configuration</a>
</li>
<li>
<a href="Dependencies.html">Dependencies</a>
</li>
<li>
<a href="Unit-tests.html">Tests</a>
</li>
<li>
<a href="Syntax.html">Syntax</a>
</li>
</ul>
</li>
</ul>
<div class="hidden-xs hidden-sm navbar-text navbar-center">
<p><b>The Meson Build System</b></p>
</div>
</div>
</div>
</nav>
<main>
<div data-extension="core" data-hotdoc-in-toplevel="True" data-hotdoc-project="Meson-documentation" data-hotdoc-ref="Cross-compilation.html" class="page_container" id="page-wrapper">
<script src="assets/js/utils.js"></script>
<div class="panel panel-collapse oc-collapsed" id="sidenav" data-hotdoc-role="navigation">
<script src="assets/js/full-width.js"></script>
<div id="sitenav-wrapper">
<iframe src="hotdoc-sitemap.html" id="sitenav-frame"></iframe>
</div>
</div>
<div id="body">
<div id="main">
<div id="page-description" data-hotdoc-role="main">
<h1 id="cross-compilation">Cross compilation</h1>
<p>Meson has full support for cross compilation through the use of
a cross build definition file. An minimal example of one such
file <code>x86_64-w64-mingw32.txt</code> for a GCC/MinGW cross compiler
targeting 64-bit Windows could be:</p>
<pre><code class="language-ini">[binaries]
c = 'x86_64-w64-mingw32-gcc'
cpp = 'x86_64-w64-mingw32-g++'
ar = 'x86_64-w64-mingw32-ar'
windres = 'x86_64-w64-mingw32-windres'
strip = 'x86_64-w64-mingw32-strip'
exe_wrapper = 'wine64'
[host_machine]
system = 'windows'
cpu_family = 'x86_64'
cpu = 'x86_64'
endian = 'little'
</code></pre>
<p>Which is then used during the <code>setup</code> phase.</p>
<pre><code class="language-sh">meson setup --cross-file x86_64-w64-mingw32.txt build-mingw
meson compile -C build-mingw
</code></pre>
<p>Since cross compiling is
more complicated than native building, let's first go over some
nomenclature. The three most important definitions are traditionally
called <em>build</em>, <em>host</em> and <em>target</em>. This is confusing because those
terms are used for quite many different things. To simplify the issue,
we are going to call these the <em>build machine</em>, <em>host machine</em> and
<em>target machine</em>. Their definitions are the following:</p>
<ul>
<li>
<em>build machine</em> is the computer that is doing the actual compiling.</li>
<li>
<em>host machine</em> is the machine on which the compiled binary will run.</li>
<li>
<em>target machine</em> is the machine on which the compiled binary's
output will run, <em>only meaningful</em> if the program produces
machine-specific output.</li>
</ul>
<p>The <code>tl/dr</code> summary is the following: if you are doing regular cross
compilation, you only care about <a href="Reference-manual_builtin_build_machine.html"><ins><code>build_machine</code></ins></a> and
<a href="Reference-manual_builtin_host_machine.html"><ins><code>host_machine</code></ins></a>. Just ignore <a href="Reference-manual_builtin_target_machine.html"><ins><code>target_machine</code></ins></a> altogether and you will
be correct 99% of the time. Only compilers and similar tools care
about the target machine. In fact, for so-called "multi-target" tools
the target machine need not be fixed at build-time like the others but
chosen at runtime, so <code>target_machine</code> <em>still</em> doesn't matter. If your
needs are more complex or you are interested in the actual details, do
read on.</p>
<p>This might be easier to understand through examples. Let's start with
the regular, not cross-compiling case. In these cases all of these
three machines are the same. Simple so far.</p>
<p>Let's next look at the most common cross-compilation setup. Let's
suppose you are on a 64 bit OSX machine and you are cross compiling a
binary that will run on a 32 bit ARM Linux board. In this case your
<em>build machine</em> is 64 bit OSX, your <em>host machine</em> is 32 bit ARM Linux
and your <em>target machine</em> is irrelevant (but defaults to the same
value as the <em>host machine</em>). This should be quite understandable as
well.</p>
<p>The usual mistake in this case is to call the OSX system the <em>host</em>
and the ARM Linux board the <em>target</em>. That's because these were their
actual names when the cross-compiler itself was compiled! Let's assume
the cross-compiler was created on OSX too. When that happened the
<em>build</em> and <em>host machines</em> were the same OSX and different from the
ARM Linux <em>target machine</em>.</p>
<p>In a nutshell, the typical mistake assumes that the terms <em>build</em>,
<em>host</em> and <em>target</em> refer to some fixed positions whereas they're
actually relative to where the current compiler is running. Think of
<em>host</em> as a <em>child</em> of the current compiler and <em>target</em> as an
optional <em>grand-child</em>. Compilers don't change their terminology when
they're creating another compiler, that would at the very least make
their user interface much more complex.</p>
<p>The most complicated case is when you cross-compile a cross compiler.
As an example you can, on a Linux machine, generate a cross compiler
that runs on Windows but produces binaries for MIPS Linux. In this case
<em>build machine</em> is x86 Linux, <em>host machine</em> is x86 Windows and
<em>target machine</em> is MIPS Linux. This setup is known as the <a href="https://en.wikipedia.org/wiki/Cross_compiler#Canadian_Cross">Canadian
Cross</a>.
As a side note, be careful when reading cross compilation articles on
Wikipedia or the net in general. It is very common for them to get
build, host and target mixed up, even in consecutive sentences, which
can leave you puzzled until you figure it out.</p>
<p>Again note that when you cross-compile something, the 3 systems
(<em>build</em>, <em>host</em>, and <em>target</em>) used when building the cross compiler
don't align with the ones used when building something with that
newly-built cross compiler. To take our Canadian Cross scenario from
above (for full generality), since its <em>host machine</em> is x86 Windows,
the <em>build machine</em> of anything we build with it is <em>x86 Windows</em>. And
since its <em>target machine</em> is MIPS Linux, the <em>host machine</em> of
anything we build with it is <em>MIPS Linux</em>. Only the <em>target machine</em>
of whatever we build with it can be freely chosen by us, say if we
want to build another cross compiler that runs on MIPS Linux and
targets Aarch64 iOS. As this example hopefully makes clear to you, the
machine names are relative and shifted over to the left by one
position.</p>
<p>If you did not understand all of the details, don't worry. For most
people it takes a while to wrap their head around these concepts.
Don't panic, it might take a while to click, but you will get the hang
of it eventually.</p>
<h2 id="defining-the-environment">Defining the environment</h2>
<p>Meson requires you to write a cross build definition file. It defines
various properties of the cross build environment. The cross file
consists of different sections.</p>
<p>There are a number of options shared by cross and native files,
<a href="Machine-files.html">here</a>. It is assumed that you have read that
section already, as this documentation will only call out options
specific to cross files.</p>
<h3 id="binaries">Binaries</h3>
<pre><code class="language-ini">[binaries]
exe_wrapper = 'wine' # A command used to run generated executables.
</code></pre>
<p>The <code>exe_wrapper</code> option defines a <em>wrapper command</em> that can be used
to run executables for this host. In this case we can use Wine, which
runs Windows applications on Linux. Other choices include running the
application with qemu or a hardware simulator. If you have this kind
of a wrapper, these lines are all you need to write. Meson will
automatically use the given wrapper when it needs to run host
binaries. This happens e.g. when running the project's test suite.</p>
<h3 id="properties">Properties</h3>
<p>In addition to the properties allowed in <a href="Machine-files.html#properties">all machine
files</a>, the cross file may contain
specific information about the cross compiler or the host machine. It
looks like this:</p>
<pre><code class="language-ini">[properties]
sizeof_int = 4
sizeof_wchar_t = 4
sizeof_void* = 4
alignment_char = 1
alignment_void* = 4
alignment_double = 4
has_function_printf = true
sys_root = '/some/path'
pkg_config_libdir = '/some/path/lib/pkgconfig'
</code></pre>
<p>In most cases you don't need the size and alignment settings, Meson
will detect all these by compiling and running some sample programs.
If your build requires some piece of data that is not listed here,
Meson will stop and write an error message describing how to fix the
issue. If you need extra compiler arguments to be used during cross
compilation you can set them with <code>[langname]_args = [args]</code>. Just
remember to specify the args as an array and not as a single string
(i.e. not as <code>'-DCROSS=1 -DSOMETHING=3'</code>).</p>
<p><em>Since 0.52.0</em> The <code>sys_root</code> property may point to the root of the
host system path (the system that will run the compiled binaries).
This is used internally by Meson to set the PKG_CONFIG_SYSROOT_DIR
environment variable for pkg-config. If this is unset the host system
is assumed to share a root with the build system.</p>
<p><em>Since 0.54.0</em> The pkg_config_libdir property may point to a list of
path used internally by Meson to set the PKG_CONFIG_LIBDIR environment
variable for pkg-config. This prevents pkg-config from searching cross
dependencies in system directories.</p>
<p>One important thing to note, if you did not define an <code>exe_wrapper</code> in
the previous section, is that Meson will make a best-effort guess at
whether it can run the generated binaries on the build machine. It
determines whether this is possible by looking at the <code>system</code> and
<code>cpu_family</code> of build vs host. There will however be cases where they
do match up, but the build machine is actually not compatible with the
host machine. Typically this will happen if the libc used by the build
and host machines are incompatible, or the code relies on kernel
features not available on the build machine. One concrete example is a
macOS build machine producing binaries for an iOS Simulator x86-64
host. They're both <code>darwin</code> and the same architecture, but their
binaries are not actually compatible. In such cases you may use the
<code>needs_exe_wrapper</code> property to override the auto-detection:</p>
<pre><code class="language-ini">[properties]
needs_exe_wrapper = true
</code></pre>
<h3 id="machine-entries">Machine Entries</h3>
<p>The next bit is the definition of host and target machines. Every
cross build definition must have one or both of them. If it had
neither, the build would not be a cross build but a native build. You
do not need to define the build machine, as all necessary information
about it is extracted automatically. The definitions for host and
target machines look the same. Here is a sample for host machine.</p>
<pre><code class="language-ini">[host_machine]
system = 'windows'
subsystem = 'windows'
kernel = 'nt'
cpu_family = 'x86'
cpu = 'i686'
endian = 'little'
</code></pre>
<p>These values define the machines sufficiently for cross compilation
purposes. The corresponding target definition would look the same but
have <code>target_machine</code> in the header. These values are available in
your Meson scripts. There are three predefined variables called,
surprisingly, <a href="Reference-manual_builtin_build_machine.html"><ins><code>build_machine</code></ins></a>, <a href="Reference-manual_builtin_host_machine.html"><ins><code>host_machine</code></ins></a> and
<a href="Reference-manual_builtin_target_machine.html"><ins><code>target_machine</code></ins></a>. Determining the operating system of your host
machine is simply a matter of calling <code>host_machine.system()</code>.
Starting from version 1.2.0 you can get more fine grained information
using the <code>.subsystem()</code> and <code>.kernel()</code> methods. The return values of
these functions are documented in <a href="Reference-tables.html">the reference table
page</a>.</p>
<p>There are two different values for the CPU. The first one is
<code>cpu_family</code>. It is a general type of the CPU. This should have a
value from <a href="Reference-tables.html#cpu-families">the CPU Family table</a>.
<em>Note</em> that Meson does not add <code>el</code> to end cpu_family value for little
endian systems. Big endian and little endian mips are both just
<code>mips</code>, with the <code>endian</code> field set appropriately.</p>
<p>The second value is <code>cpu</code> which is a more specific subtype for the
CPU. Typical values for a <code>x86</code> CPU family might include <code>i386</code> or
<code>i586</code> and for <code>arm</code> family <code>armv5</code> or <code>armv7hl</code>. Note that CPU type
strings are very system dependent. You might get a different value if
you check its value on the same machine but with different operating
systems.</p>
<p>If you do not define your host machine, it is assumed to be the build
machine. Similarly if you do not specify target machine, it is assumed
to be the host machine.</p>
<h2 id="starting-a-cross-build">Starting a cross build</h2>
<p>Once you have the cross file, starting a build is simple</p>
<pre><code class="language-console">$ meson setup builddir --cross-file cross_file.txt
</code></pre>
<p>Once configuration is done, compilation is started by invoking <code>meson compile</code>
in the usual way.</p>
<h2 id="introspection-and-system-checks">Introspection and system checks</h2>
<p>The main <em>meson</em> object provides two functions to determine cross
compilation status.</p>
<pre><code class="language-meson"><a href="Reference-manual_builtin_meson.html#mesonis_cross_build"><ins>meson.is_cross_build()</ins></a> # returns true when cross compiling
<a href="Reference-manual_builtin_meson.html#mesoncan_run_host_binaries"><ins>meson.can_run_host_binaries()</ins></a> # returns true if the host binaries can be run, either with a wrapper or natively
</code></pre>
<p>You can run system checks on both the system compiler or the cross
compiler. You just have to specify which one to use.</p>
<pre><code class="language-meson">build_compiler = <a href="Reference-manual_builtin_meson.html#mesonget_compiler"><ins>meson.get_compiler</ins></a>('c', native : true)
host_compiler = <a href="Reference-manual_builtin_meson.html#mesonget_compiler"><ins>meson.get_compiler</ins></a>('c', native : false)
build_int_size = build_compiler.sizeof('int')
host_int_size = host_compiler.sizeof('int')
</code></pre>
<h2 id="mixing-host-and-build-targets">Mixing host and build targets</h2>
<p>Sometimes you need to build a tool which is used to generate source
files. These are then compiled for the actual target. For this you
would want to build some targets with the system's native compiler.
This requires only one extra keyword argument.</p>
<pre><code class="language-meson">native_exe = executable('mygen', 'mygen.c', native : true)
</code></pre>
<p>You can then take <code>native_exe</code> and use it as part of a generator rule or anything else you might want.</p>
<h2 id="using-a-custom-standard-library">Using a custom standard library</h2>
<p>Sometimes in cross compilation you need to build your own standard
library instead of using the one provided by the compiler. Meson has
built-in support for switching standard libraries transparently. The
invocation to use in your cross file is the following:</p>
<pre><code class="language-ini">[properties]
c_stdlib = ['mylibc', 'mylibc_dep'] # Subproject name, variable name
</code></pre>
<p>This specifies that C standard library is provided in the Meson
subproject <code>mylibc</code> in internal dependency variable <code>mylibc_dep</code>. It
is used on every cross built C target in the entire source tree
(including subprojects) and the standard library is disabled. The
build definitions of these targets do not need any modification.</p>
<p>Note that it is supported for any language, not only <code>c</code>, using <code><lang>_stdlib</code>
property.</p>
<p>Since <em>0.56.0</em> the variable name parameter is no longer required as long as the
subproject calls <code>meson.override_dependency('c_stdlib', mylibc_dep)</code>.
The above example becomes:</p>
<pre><code class="language-ini">[properties]
c_stdlib = 'mylibc'
</code></pre>
<h2 id="changing-cross-file-settings">Changing cross file settings</h2>
<p>Cross file settings are only read when the build directory is set up
the first time. Any changes to them after the fact will be ignored.
This is the same as regular compiles where you can't change the
compiler once a build tree has been set up. If you need to edit your
cross file, then you need to wipe your build tree and recreate it from
scratch.</p>
<h2 id="custom-data">Custom data</h2>
<p>You can store arbitrary data in <code>properties</code> and access them from your
Meson files. As an example if your cross file has this:</p>
<pre><code class="language-ini">[properties]
somekey = 'somevalue'
</code></pre>
<p>then you can access that using the <code>meson</code> object like this:</p>
<pre><code class="language-meson">myvar = meson.get_external_property('somekey')
# myvar now has the value 'somevalue'
</code></pre>
<h2 id="cross-file-locations">Cross file locations</h2>
<p>As of version 0.44.0 Meson supports loading cross files from system
locations (except on Windows). This will be
$XDG_DATA_DIRS/meson/cross, or if XDG_DATA_DIRS is undefined, then
/usr/local/share/meson/cross and /usr/share/meson/cross will be tried
in that order, for system wide cross files. User local files can be
put in $XDG_DATA_HOME/meson/cross, or ~/.local/share/meson/cross if
that is undefined.</p>
<p>The order of locations tried is as follows:</p>
<ul>
<li>A file relative to the local dir</li>
<li>The user local location</li>
<li>The system wide locations in order</li>
</ul>
<p>Distributions are encouraged to ship cross files either with their
cross compiler toolchain packages or as a standalone package, and put
them in one of the system paths referenced above.</p>
<p>These files can be loaded automatically without adding a path to the
cross file. For example, if a ~/.local/share/meson/cross contains a
file called x86-linux, then the following command would start a cross
build using that cross files:</p>
<pre><code class="language-sh">meson setup builddir/ --cross-file x86-linux
</code></pre>
</div>
</div>
<div id="search_results">
<p>The results of the search are</p>
</div>
<div id="footer">
<hr>
<div class="license-description">
Website licensing information are available on the <a href="legal.html">Legal</a> page.
</div>
</div>
</div>
<div id="toc-column">
<div class="edit-button">
<a href="https://github.com/mesonbuild/meson/edit/master/docs/markdown/Cross-compilation.md" data-hotdoc-role="edit-button">Edit on GitHub</a>
</div>
<div id="toc-wrapper">
<nav id="toc"></nav>
</div>
</div>
</div>
</main>
<script src="assets/js/navbar_offset_scroller.js"></script>
</body>
</html>