blob: daf007e6df33a4b4abfb3f226bc3cb40eba55c73 (
plain)
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
|
Binutils Package
================
Building the Binutils Package
-----------------------------
If you want to temporarily change the targets for which Binutils is built, run
the following commands before building:
$ ./config clean
$ PKG_TARGETS='list of architectures' ./config
The default targets are listed in the `targets.in` file.
To configure Binutils to be built for all default targets, run the following
commands before building:
$ ./config clean
$ ./config
Binutils Build System Mangling
------------------------------
[See `patches/01_pass-some-dirs-to-child-makes.patch` for some background
information.]
An alternative to `patches/01_pass-some-dirs-to-child-makes.patch` is to run
make in each subdirectory ourselves instead of letting the top-level makefile do
it for us. This way, we can leave the build system untouched and directly give
each child make process the required macro settings.
There are ten subdirectories in which we would need to run make (though of
course we don't currently enable some of them, e.g. `gold`):
* `bfd`
* `opcodes`
* `binutils`
* `etc`
* `gas`
* `gold`
* `gprof`
* `intl`
* `ld`
* `libiberty`
The disadvantage to this is a higher maintenance cost: we need to keep track of
the subdirectories in which we need to run make. We need to watch out for
changes to the dependencies of `install-host` and `install-target` in Binutils's
Makefile.in (unlikely) and changes in the features (e.g. gold) we enable
(likely).
The trivial patch (which adds just three lines) should apply cleanly across
Binutils releases, so it seems best to just stick with that.
|
