You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This docker container has been created to allow us to easily crosscompile the c++ tools starting from this repo. The idea comes from [multiarch/crossbuild](https://github.com/multiarch/crossbuild), but this container unfortunately is outdated, the apt sources are no longer available.
3
+
This docker container has been created to allow us to easily crosscompile our c++ tools. The idea comes from [multiarch/crossbuild](https://github.com/multiarch/crossbuild), but that container unfortunately is outdated and the apt sources are no longer available.
4
4
5
5
## Starting Image
6
-
The starting image is [ubuntu:latest](https://hub.docker.com/_/ubuntu) (The ubuntu:latest tag points to the "latest LTS", since that's the version recommended for general use.) at the time of writing latest points to Ubuntu 20.04 focal.
6
+
The starting image is [ubuntu:latest](https://hub.docker.com/_/ubuntu) (The ubuntu:latest tag points to the "latest LTS", since that's the version recommended for general use.) at the time of writing latest points to Ubuntu 22.04 jammy.
7
7
8
8
The starting image is only marginally important, since internally we use manually installed toolchains.
9
9
@@ -18,21 +18,20 @@ Inside that archive there are:
18
18
19
19
Regarding the two ubuntu toolchains: in the beginning we tried to use the ones shipped with 12.04 but they caused some build errors because they were too old, so we upgraded to 16.04 ones. They are created using [crosstool-ng](https://github.com/crosstool-ng/crosstool-ng).
20
20
21
-
22
21
Apparently, osxcross does not have tags or version so we checkout a specific commit in order to have a pinned environment.
23
22
24
23
The last toolchain required to crosscompile for windows is `mingw-w64` and it's installed through `apt` along with other useful packages.
25
24
26
-
Once the toolchains are installed in `/opt` we add the binaries to the `PATH` env variable, to easily call them in the CI.
25
+
Once the toolchains are installed in `/opt` we add the binaries to the `PATH` env variable, to easily use them in the CI.
27
26
28
27
## Copying and Building Libraries
29
-
As explained in the other [`README.md`](deps/README.md) there are some libraries that needs to be compiled. This is achieved by copying `deps/` directory inside `/opt/lib/` in the container and then by using [`build_libs.sh`](deps/build_libs.sh) script [here](Dockerfile#L47-L55)
28
+
As explained in the other [`README.md`](deps/README.md) there are some libraries that needs to be compiled, in order to create static binaries. This is achieved by copying `deps/` directory inside `/opt/lib/` in the container and then by using [`build_libs.sh`](deps/build_libs.sh) script [here](Dockerfile#L53-L59)
30
29
31
30
## Multi-stage build
32
-
To reduce the overall dimesion of the docker image we used the [multi-stage build](https://learnk8s.io/blog/smaller-docker-images).
31
+
To reduce the overall dimension of the docker image we used the [multi-stage build](https://learnk8s.io/blog/smaller-docker-images). But the image still 8GB.
33
32
34
33
## How to build and use the container
35
34
Usefull commands you can use:
36
-
-`docker build -t ghcr.io/arduino/crossbuild:<version> docker/` to build the container
35
+
-`docker build -t ghcr.io/arduino/crossbuild:<version> .` to build the container
37
36
-`docker push ghcr.io/arduino/crossbuild:<version>` to push the image to [github remote registry](https://docs.github.com/en/packages/guides/container-guides-for-github-packages)
38
-
-`docker run -it --name crossbuild -v $PWD:/workdir ghcr.io/arduino/crossbuild:<version>` to get a shell inside the container and use the toolchains available inside (like the CI does).
37
+
-`docker run -it --name crossbuild -v $PWD:/workdir ghcr.io/arduino/crossbuild:<version>` to get a shell inside the container and use the toolchains available inside (just like the CI does).
The `deps/` folder contains the dependencies used to build and link statically `picotool` and `elf2uf2`: the libraries `libusb` and `libudev`.
3
-
The `deps/` folder contains also a bash script used by the docker container to successfully build them with different toolchains and with different targets.
4
-
This way they are already compiled and usable by the CI during the building/linking phase!
2
+
The `deps/` folder contains the library dependencies used to build and link statically tools, like `picotool` and `elf2uf2` (the libraries `libusb` and `libudev`...).
3
+
The `deps/` folder contains also a bash script used by the [Dockerfile](../Dockerfile) to successfully build them with different toolchains and with different targets.
4
+
This way they are ready when used by the CI during the building/linking phase!
5
5
6
-
They come respectively from [here](https://github.com/arduino/OpenOCD-build-script/tree/static/libusb-1.0.20)
`build_libs.sh` is used by the [Dockerfile](../Dockerfile#L49-L55):
17
+
`build_libs.sh` is used by the [Dockerfile](../Dockerfile#L53-L59):
11
18
Basically during the docker build phase the libraries are compiled with every toolchain available in the Docker container. Other libraries can be added, the [`build_libs.sh`](build_libs.sh) script needs to be adapted, but the Dockerfile should be ok.
12
-
13
-
## libusbudev
14
-
libusbudev is the result of merging the two `.a` files with a command line tool called `ar`. This is done to ease the linking phase done by the [CI](.github/workflows/release.yml#L87) passing a single static library. See `LIBUSBUDEV` env variable [here](../../.github/workflows/release.yml#L67) and [here](../../.github/workflows/release.yml#L71).
15
-
For macos is not required to merge the two libraries because libudev is not a requirement, so macos uses `libusb.a` only: thus the distinction between the two platforms. Infact libusb for mac is the last one built in the [Dockerfile](../Dockerfile#L55).
16
-
17
-
`libusbudev.a` is created by the `build_libs.sh` the directory structure created is the following:
18
-
19
-
```
20
-
/opt/lib/
21
-
|-- aarch64-linux-gnu
22
-
| |-- libudev
23
-
| |-- libusb
24
-
| `-- libusbudev.a
25
-
|-- arm-linux-gnueabihf
26
-
| |-- libudev
27
-
| |-- libusb
28
-
| `-- libusbudev.a
29
-
|-- build_libs.sh
30
-
|-- eudev-3.2.10
31
-
|-- i686-ubuntu16.04-linux-gnu
32
-
| |-- libudev
33
-
| |-- libusb
34
-
| `-- libusbudev.a
35
-
|-- i686-w64-mingw32
36
-
| |-- libudev
37
-
| |-- libusb
38
-
| `-- libusbudev.a
39
-
|-- libusb-1.0.20
40
-
`-- x86_64-ubuntu16.04-linux-gnu
41
-
|-- libudev
42
-
|-- libusb
43
-
`-- libusbudev.a
44
-
```
45
-
46
-
The original `libusb.a` is available in `/opt/lib/libusb-1.0.20/libusb/.libs/libusb-1.0.a`
47
-
and `libudev.a` is available in `/opt/lib/eudev-3.2.10/src/libudev/.libs/libudev.a`
0 commit comments