Differences
This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
compile_batocera.linux [2020/07/31 16:08] – [Install prerequisites] ordovice | compile_batocera.linux [2024/01/22 22:26] (current) – [Install prerequisites] Correct rpi models for bcm2836 and bcm2837 boards maximumentropy | ||
---|---|---|---|
Line 1: | Line 1: | ||
- | ===== Compile batocera.linux ===== | + | ====== Compile batocera.linux |
- | The official, and recommended, way to compile batocera.linux is by using a development container made on purpose with Docker. Although you can do it directly on your Linux machine, if it's a supported Ubuntu Linux. | + | The official and recommended way to compile batocera.linux is by using a development container made on purpose with Docker. Although you can do it directly on your Linux machine, if it's a supported Ubuntu Linux. |
- | ==== Install prerequisites ==== | + | Note that it's also possible to compile batocera.linux within an [[compiling_lxc_containers|LXC container]] but it's not recommended |
- | Choose either Docker | + | |
- | Make sure you have a reasonably fast CPU, and at least 8GB of RAM. If you have a CPU with 8 cores or more (lucky you!), you might need more than 8GB RAM to compile | + | If you are not familiar |
- | === Docker | + | ===== Install prerequisites ===== |
- | If you already have a working Docker installation on your Linux system, you just need to install '' | + | |
- | Otherwise, the first step is to install Docker on your machine. Each OS and Linux distribution has a particular way to install Docker. | + | Choose either [[# |
+ | |||
+ | Make sure you have a reasonably fast CPU, and at least **8GB of RAM** (even **12GB+** if you need to compile MAME). If you have a CPU with 8 cores/16 threads or more (lucky you!), you might need more than 16 GB RAM to compile batocera.linux with all threads in parallel. You also need **between 80GB and 130GB of free disk space** for each platform you intend to compile for in order to download and compile | ||
+ | |||
+ | For reference, here are some **estimates** of the space required for building certain platforms: | ||
+ | * **x86_64**: 170 GB (for Batocera 36) | ||
+ | * **bcm2837** (rpi3): 80 GB | ||
+ | * **bcm2836** (rpi2): 70 GB | ||
+ | * **s905gen2** (radxa zero): 65 GB | ||
+ | * **rpizero**: | ||
+ | |||
+ | <WRAP center round tip> | ||
+ | If compiling inside of a VM, you may need to set its CPU type to '' | ||
+ | </ | ||
+ | |||
+ | ==== Install dev tools ==== | ||
+ | |||
+ | If never having compiled on the machine before you may need to install | ||
+ | |||
+ | * Ubuntu: | ||
+ | * To install the basic dev tools: '' | ||
+ | * Fedora: | ||
+ | * o check the packages that will be installed with the group, run: '' | ||
+ | * To install them: '' | ||
+ | * Arch: | ||
+ | * To install the dev tools: '' | ||
+ | |||
+ | If you wish to be frugal, the only essential packages on the host OS for compiling Batocera in Docker are '' | ||
+ | |||
+ | ==== Docker ==== | ||
+ | |||
+ | If you already have a working | ||
+ | |||
+ | Each OS and Linux distribution has a particular way to install Docker. | ||
+ | |||
+ | //Please note that most developers use Ubuntu Linux to compile batocera.linux. In January 2022, Docker on Windows was not stable enough to compile Batocera.// | ||
- | //Please note that most developers use Ubuntu Linux to compile batocera.linux. In October 2018, Docker on Windows is not stable enough to compile Batocera.// \\ | ||
In March 2020, with the Docker container running as non-root (regular user), you can compile Batocera on MacOS Mojave 10.14 (Darwin 18.0.0). | In March 2020, with the Docker container running as non-root (regular user), you can compile Batocera on MacOS Mojave 10.14 (Darwin 18.0.0). | ||
* Linux Ubuntu/ | * Linux Ubuntu/ | ||
- | * Installing from the Distribution packages is not recommended. | + | * Installing from the Distribution packages is not recommended. |
* To be able to run docker without root privileges don't forget to add your user to the //docker// group: | * To be able to run docker without root privileges don't forget to add your user to the //docker// group: | ||
- | * Linux Solus: '' | + | |
+ | * Installing from the snap/ | ||
+ | * To be able to run Docker without root privileges and at boot, don't forget to add your user to the //docker// group. Fedora' | ||
+ | sudo gpasswd -a ${USER} docker | ||
+ | sudo systemctl restart docker | ||
+ | newgrp docker</ | ||
+ | * To start the docker daemon at boot: '' | ||
+ | | ||
+ | * Arch Linux: '' | ||
* (for reference) MacOS: see [[https:// | * (for reference) MacOS: see [[https:// | ||
* (for reference) Windows: see [[https:// | * (for reference) Windows: see [[https:// | ||
- | Once Docker is installed, you have to get it up and running (depending on your OS, for Linux Solus for example, you would start it up with '' | + | ==== Direct Compilation ==== |
- | Git is used to download | + | The way to install |
- | === Direct Compilation | + | === Ubuntu 18.04 === |
- | The way to install the necessary packages vary for each Linux distribution. You can find the necessary packages for Ubuntu | + | May also work with Ubuntu |
- | * Ubuntu 18.04 (might still work with 16.04 too) | + | < |
+ | sudo apt-get install build-essential git libncurses5-dev libssl-dev mercurial texinfo zip default-jre imagemagick subversion hgsubversion autoconf automake bison scons libglib2.0-dev bc mtools u-boot-tools flex wget cpio dosfstools libtool | ||
+ | sudo dpkg --add-architecture i386 | ||
+ | sudo apt-get update | ||
+ | sudo apt-get install libc6:i386 libncurses5: | ||
+ | </ | ||
- | sudo apt-get install build-essential git libncurses5-dev libssl-dev mercurial texinfo zip default-jre imagemagick subversion | + | === Ubuntu 20.04 === |
- | | + | |
- | | + | Includes requirements for some experimental packages. |
- | | + | |
- | * Ubuntu 20.04 (Includes requirements for some experimental packages) | + | < |
+ | sudo apt-get install build-essential git libncurses5-dev libssl-dev mercurial texinfo zip default-jre imagemagick subversion autoconf automake bison scons libglib2.0-dev bc mtools u-boot-tools flex wget cpio dosfstools libtool | ||
+ | sudo dpkg --add-architecture i386 | ||
+ | sudo apt-get update | ||
+ | sudo apt-get install libc6:i386 libncurses5: | ||
+ | pip3 install conan | ||
+ | </ | ||
+ | |||
+ | ===== Preparations ===== | ||
+ | |||
+ | ==== Download the batocera.linux sources ==== | ||
+ | |||
+ | <WRAP center round info> | ||
+ | If you are already set up to [[: | ||
+ | |||
+ | < | ||
+ | cd batocera.linux | ||
+ | git checkout master | ||
+ | </ | ||
+ | |||
+ | and skip the rest of this step. | ||
+ | </ | ||
- | sudo apt-get install build-essential git libncurses5-dev libssl-dev mercurial texinfo zip default-jre imagemagick subversion autoconf automake bison scons libglib2.0-dev bc mtools u-boot-tools flex wget cpio dosfstools libtool | ||
- | sudo dpkg --add-architecture i386 | ||
- | sudo apt-get update | ||
- | sudo apt-get install libc6:i386 libncurses5: | ||
- | | ||
- | pip3 install conan | ||
- | ==== Preparations ==== | ||
- | === Download the batocera.linux sources === | ||
Choose a work directory (your $HOME?) and clone the batocera.linux source code: | Choose a work directory (your $HOME?) and clone the batocera.linux source code: | ||
- | | + | <code bash> |
+ | git clone https:// | ||
+ | </ | ||
Enter the newly created directory. | Enter the newly created directory. | ||
- | cd batocera.linux | + | <code bash> |
+ | cd batocera.linux | ||
+ | </ | ||
- | If the '' | + | By default, |
- | git submodule init | + | <code bash> |
- | | + | git submodule init |
+ | git submodule update | ||
+ | </ | ||
You only need to do this once. | You only need to do this once. | ||
- | If you use Docker, create the image of the container: | + | ===== Compilation ===== |
- | | + | ==== Easy compilation ==== |
- | Then start it //by using the repository you just cloned as the /build folder of the container itself//, with: | + | To make things easier, there is makefile [[https://github.com/batocera-linux/batocera.linux/pull/ |
- | | + | **1. Add your user to the docker |
- | If you run the docker | + | If you haven' |
+ | and [[https:// | ||
- | === Choose the target you want to build === | + | <code bash> |
+ | sudo usermod -a -G docker $USER | ||
+ | </ | ||
- | Depending on the target you want to build Batocera for, you need to select one of the batocera-XXXXX_defconfig files, where //XXXX// has to be replaced with the architecture you are building to. Available ones are: | + | Enter your password when prompted |
- | | + | **2. Start up Docker** |
- | | + | |
- | | + | |
- | | + | |
- | * odroidn2 | + | |
- | * odroidxu4 | + | |
- | * odroidgoa | + | |
- | * x86_64 | + | |
- | * x86 (32 bits, old PCs) | + | |
- | * tinkerboard | + | |
- | * miqi | + | |
- | * s905 | + | |
- | * s912 | + | |
- | * rockpro64 | + | |
- | * rock960 | + | |
- | + | ||
- | You can find them all listed in the '' | + | |
- | === Compilation === | + | If you haven' |
- | To make things easier, I recommend using a prepared '' | + | <code bash> |
+ | sudo systemctl start docker.service | ||
+ | </code> | ||
- | Of course you can still use out of tree builds. So, for x86_64, you can do the following: | + | then reboot in order to make sure both the service is running. |
- | make O=$PWD/ | + | **3. Install build environment** |
- | cd output/ | + | |
- | make | + | <code bash> |
+ | make batocera-docker-image | ||
+ | </ | ||
+ | |||
+ | <WRAP center round tip> | ||
+ | You will have to update this image every once in a while with '' | ||
+ | </ | ||
+ | |||
+ | **4. Customize directories** | ||
+ | |||
+ | By default, Batocera will download dependencies to '' | ||
+ | |||
+ | <code bash> | ||
+ | make vars | ||
+ | </ | ||
+ | |||
+ | To change the directories that Batocera will build to, rename the '' | ||
+ | |||
+ | This is also how you decide which platform you are building for. If making the ordinary " | ||
+ | |||
+ | <WRAP center round todo> | ||
+ | This should be aliased in the build process. | ||
+ | </ | ||
+ | |||
+ | If intending to build Raspberry Pi: | ||
+ | < | ||
+ | Image: broadcom/ | ||
+ | Hardware: rpizero rpizerow rpi1A rpi1B rpi1A+ rpi1B+ (32-bit) | ||
+ | |||
+ | Image: broadcom/ | ||
+ | Hardware: rpi2B rpizero2W rpi3B rpi3A+ rpi3B+ (32-bit) | ||
+ | |||
+ | Image: broadcom/ | ||
+ | Hardware: rpizero2W rpi3B rpi3A+ rpi3B+ (64-bit) | ||
+ | |||
+ | Image: broadcom/ | ||
+ | Hardware: rpi4B pi400 cm4 (64-bit) | ||
+ | </ | ||
+ | |||
+ | The RPi 3 build currently uses the 64-bit build. | ||
+ | |||
+ | **5. Build an image** | ||
+ | |||
+ | The build command is different for each target architecture, | ||
+ | |||
+ | <code bash> | ||
+ | make x86_64-build | ||
+ | </ | ||
+ | |||
+ | You can check valid targets architectures by running '' | ||
+ | |||
+ | <WRAP center round important> | ||
+ | Every time a new image is built, the '' | ||
+ | </ | ||
+ | |||
+ | **6. Shell** | ||
+ | |||
+ | It's also possible to get a shell to the desired build environment. Similar to '' | ||
+ | |||
+ | <code bash> | ||
+ | make x86_64-shell | ||
+ | </ | ||
+ | |||
+ | <WRAP center round tip 60%> | ||
+ | Once in the shell, it is possible to bring up menuconfig from here to configure the Linux kernel from a nicely-presented UI: | ||
+ | |||
+ | < | ||
+ | make x86_64-shell | ||
+ | make menuconfig | ||
+ | </ | ||
+ | |||
+ | {{: | ||
+ | </ | ||
+ | |||
+ | **7. Build a single package** | ||
+ | |||
+ | To build a single package, you can open a shell or use the '' | ||
+ | |||
+ | <code bash> | ||
+ | make rk3326-pkg PKG=batocera-splash | ||
+ | make x86_64-shell PKG=libretro-mame | ||
+ | </ | ||
+ | |||
+ | <WRAP center round important> | ||
+ | Although this will build package itself, it does not do so in the same way that the regular '' | ||
+ | </ | ||
+ | |||
+ | **8. ccache** | ||
+ | |||
+ | To enable ccache for all builds, add the necessary options to '' | ||
+ | |||
+ | **9. Compile clean builds** | ||
+ | |||
+ | This will clear all the data in '' | ||
+ | |||
+ | * If building an older version of Batocera, and you've already built a future version of it, always do a cleanbuild to ensure that the packages in the build cache do not cause conflicts with older packages producing unintelligible error messages. | ||
+ | * Avoid cherry-picking commits; every commit (in Batocera at least) may be dependent on another previous commit, and the effect daisy chains even with commits that seem otherwise independent. If a single package has been built with a cherry-picked commit, cleanbuild to ensure no future errors. | ||
+ | * After building an older version and wanting to build the most recent version again, do another cleanbuild. Honestly, the only time you can consistently use the regular build command is if you're solely just following master branch and continually building without modifications. | ||
+ | * When facing seemingly random errors that other devs are not facing when building packages, do a cleanbuild. This can also include errors that arise from the compilation process being interrupted. | ||
+ | |||
+ | <code bash> | ||
+ | make x86_64-cleanbuild | ||
+ | </ | ||
+ | | ||
+ | **10. Build a webserver to upgrade your Batocera** | ||
+ | |||
+ | You can easily upgrade your Batocera test machine with the build you have just compiled. Let's imagine your build box's IP address is '' | ||
+ | |||
+ | <code bash> | ||
+ | make x86_64-webserver | ||
+ | </ | ||
+ | |||
+ | Then, you can launch an upgrade from your Batocera test box. If your build box hosting the web server is on 10.0.0.10, you can simply upgrade to your freshly brewed build by entering from your Batocera SSH: | ||
+ | |||
+ | <code bash> | ||
+ | batocera-upgrade http:// | ||
+ | </ | ||
+ | |||
+ | **11. Clean up outdated files from previous builds** | ||
+ | |||
+ | Over time, there are many packages updates, and by default, all older versions of the source packages and the corresponding binary builds are kept in your Batocera working directory. Here are a few commands that will help you reclaim storage space: | ||
+ | |||
+ | Show packages that are outdated in the '' | ||
+ | <code bash> | ||
+ | make find-dl-dups | ||
+ | </ | ||
+ | |||
+ | Remove all these outdated packages from your '' | ||
+ | <code bash> | ||
+ | make remove-dl-dups | ||
+ | </ | ||
+ | |||
+ | Show directories in the '' | ||
+ | <code bash> | ||
+ | make x86_64-find-build-dups | ||
+ | </ | ||
+ | |||
+ | Remove all these outdated build directories: | ||
+ | <code bash> | ||
+ | make x86_64-remove-build-dups | ||
+ | </ | ||
+ | |||
+ | Of course '' | ||
+ | |||
+ | ==== Traditional compilation method ==== | ||
+ | |||
+ | Of course you can still use out of tree builds to compile Batocera. So, for x86_64, you can do the following: | ||
+ | |||
+ | <code bash> | ||
+ | make O=$PWD/ | ||
+ | cd output/ | ||
+ | make | ||
+ | </ | ||
Source tree will stay pristine and we be reused for other builds following the same procedure with a different output directory. For example: | Source tree will stay pristine and we be reused for other builds following the same procedure with a different output directory. For example: | ||
- | | + | <code bash> |
- | cd output/ | + | make O=$PWD/ |
- | make | + | cd output/ |
+ | make | ||
+ | </ | ||
Then, you can take some time for a coffee (or two, or two hundreds actually). Depending on how powerful your CPU is, how much RAM you have, and how fast your SSD/HDD is, compiling a whole Batocera system can take many hours. Don't forget, it's the full OS with all the emulators that we are compiling here, it's not a small task. | Then, you can take some time for a coffee (or two, or two hundreds actually). Depending on how powerful your CPU is, how much RAM you have, and how fast your SSD/HDD is, compiling a whole Batocera system can take many hours. Don't forget, it's the full OS with all the emulators that we are compiling here, it's not a small task. | ||
- | Please also mind that the process will take a significant amount of space, **so ensure to have at least 50GB free on that partition**. | + | Please also mind that the process will take a significant amount of space, **so ensure to have between |
+ | |||
+ | ===== Locating the image ===== | ||
- | ==== Locating the image ==== | ||
Exit the container if you ran the build inside of it. | Exit the container if you ran the build inside of it. | ||
- | The output will be under **output/ | + | The output will be under **output/ |
- | For instance: output/ | + | For instance: |
- | You can then flash it with Etcher | + | You can then flash it with Raspberry Pi Imager |
- | or by using dd if you don't want to leave the command | + | |
+ | <code bash> | ||
+ | make DEV=/ | ||
+ | </ | ||
+ | |||
+ | ===== Tips ===== | ||
+ | |||
+ | ==== Building configuration ==== | ||
+ | |||
+ | Build options in '' | ||
+ | |||
+ | <WRAP center round important> | ||
+ | It is important that each option has a leading space character at the start of its line. Do not remove this. | ||
+ | </ | ||
+ | |||
+ | By default, Docker will take all of your computer' | ||
+ | |||
+ | < | ||
+ | | ||
+ | </ | ||
+ | |||
+ | You can also limit compilation to a single core by setting '' | ||
+ | |||
+ | < | ||
+ | | ||
+ | </ | ||
+ | |||
+ | By default, buildroot will use a cache to store its most commonly compiled functions. This improves repeated compilation time at the cost of disk space. If disk space is at a premium, you can set a cap to this by appending this to the '' | ||
+ | |||
+ | < | ||
+ | | ||
+ | </ | ||
+ | |||
+ | ==== Download sources ==== | ||
- | gunzip output/ | ||
- | dd if=output/ | ||
- | | ||
- | ==== Tips ==== | ||
- | === Download sources === | ||
You can download sources from Internet before compiling by running the following command, assuming you started with x86_64: | You can download sources from Internet before compiling by running the following command, assuming you started with x86_64: | ||
- | | + | |
- | make source | + | <code bash> |
+ | cd output/ | ||
+ | make source | ||
+ | </ | ||
| | ||
Personally, I even run it during 10 minutes and then run make in parallel. | Personally, I even run it during 10 minutes and then run make in parallel. | ||
- | === Follow the current | + | ==== Follow the current |
If you want to check on the current status for your x86_64 build: | If you want to check on the current status for your x86_64 build: | ||
- | | + | <code bash> |
- | + | tail -f output/x86_64/ | |
+ | </ | ||
+ | |||
+ | ==== What isn't compiled yet? ==== | ||
- | === What isn't compiled yet? === | ||
If you ran make source, you can easily find what's remaining to compile by running : | If you ran make source, you can easily find what's remaining to compile by running : | ||
- | | + | <code bash> |
+ | for i in output/ | ||
+ | </ | ||
- | === Sharing a single download folder among all builds === | + | ==== Sharing a single download folder among all builds ==== |
- | docker run -it --rm -v $PWD:/build -v $HOME/ | + | |
- | === List docker images === | + | <code bash> |
- | docker | + | docker |
+ | </ | ||
- | === Remove docker | + | ==== List Docker |
- | docker rmi [image] | + | |
- | === List docker containers === | + | <code bash> |
- | docker | + | docker |
+ | </ | ||
- | === Remove docker containers | + | ==== Update Docker images ==== |
- | docker kill [container name] | + | |
- | === Folder structure and other tips === | + | <code bash> |
+ | make update-docker-image | ||
+ | </ | ||
+ | |||
+ | ==== Remove Docker images ==== | ||
+ | |||
+ | <code bash> | ||
+ | docker rmi < | ||
+ | </ | ||
+ | |||
+ | ==== List Docker containers ==== | ||
+ | |||
+ | <code bash> | ||
+ | docker ps | ||
+ | </ | ||
+ | |||
+ | ==== Remove Docker containers ==== | ||
+ | |||
+ | <code bash> | ||
+ | docker kill [container name] | ||
+ | </ | ||
+ | |||
+ | ==== Folder structure and other tips ==== | ||
Follow [[batocera.linux_buildroot_modifications|this page]] to know more about the structure of the Batocera source code and where your modifications need to be made. | Follow [[batocera.linux_buildroot_modifications|this page]] to know more about the structure of the Batocera source code and where your modifications need to be made. | ||
- | === qt5base compilation error in ubuntu docker === | + | ==== qt5base compilation error in ubuntu docker ==== |
- | Add --security-opt seccomp: | + | |
+ | Add '' | ||
As of February 2020, it looks like this step is not required any longer. | As of February 2020, it looks like this step is not required any longer. | ||
+ | |||
+ | ==== Compiling Batocera inside of an LXC container ==== | ||
+ | |||
+ | Refer to [[: | ||
+ | |||
+ | ==== Skip compiling a certain package ==== | ||
+ | |||
+ | Sometimes during compilation you may come across a package that won't compile, but you want to check for if a future package is okay or not. You can skip any partially built package by creating its [[# | ||
+ | |||
+ | For a more permanent (and somewhat easier to use) skip, a package can be skipped in compilation by removing its mention from the '' | ||
+ | |||
+ | For instance, to skip over the PCSX2 standalone emulator and its libretro core from compiling, comment out its respective lines in '' | ||
+ | |||
+ | <code make> | ||
+ | #select BR2_PACKAGE_PCSX2 | ||
+ | #select BR2_PACKAGE_PCSX2_AVX2 | ||
+ | #select BR2_PACKAGE_LIBRETRO_PCSX2 | ||
+ | </ | ||
+ | |||
+ | ===== Define a specific platform' | ||
+ | |||
+ | Let's assume you want to compile for Raspberry Pi 3. The Buildroot configuration for that platform can be refreshed by running: | ||
+ | |||
+ | make batocera-rpi3_defconfig | ||
+ | | ||
+ | This step creates the file '' | ||
+ | |||
+ | If the '' | ||
+ | |||
+ | '' | ||
+ | |||
+ | '' | ||
+ | |||
+ | In other words, '' | ||
+ | |||
+ | ===== Troubleshooting ===== | ||
+ | |||
+ | ==== Docker doesn' | ||
+ | |||
+ | If using Docker to compile, you must [[https:// | ||
+ | |||
+ | In case it's not possible to do that for your user, a temporary workaround is to simply run the command with elevated privileges: '' | ||
+ | |||
+ | ==== Ignoring batocera.mk ==== | ||
+ | |||
+ | If batocera.mk is being tracked in your local git repo, the following command may be used to explicitly ignore it: | ||
+ | |||
+ | <code bash> | ||
+ | git update-index --assume-unchanged batocera.mk | ||
+ | </ | ||
+ | |||
+ | ==== Compilation stops early when trying to apply the Linux kernel patches ==== | ||
+ | |||
+ | This usually happens when the current Linux kernel in the folder is incomplete or was halted during compilation. To fix it, run the following: | ||
+ | |||
+ | <code bash> | ||
+ | make x86_64-shell | ||
+ | rm -rf build/ | ||
+ | </ | ||
+ | |||
+ | This can also be used to " | ||
+ | |||
+ | ==== Compilation stops at a random time ==== | ||
+ | |||
+ | First, ensure that you have [[# | ||
+ | |||
+ | This may happen at any point during compilation, | ||
+ | |||
+ | For example, if bsnes was the emulator causing the compilation issues, the '' | ||
+ | |||
+ | <code bash> | ||
+ | touch ~/ | ||
+ | </ | ||
+ | |||
+ | If that goes to its end, then it can be recompiled with the following actions: | ||
+ | |||
+ | <code bash> | ||
+ | rm -rf ~/ | ||
+ | make libretro-bsnes-hd | ||
+ | </ | ||
+ | |||
+ | This can be used to determine if it is a local issue with that package or a global issue with Batocera. | ||
+ | |||
+ | ==== Compilation stops at a random time and even after using stamps I can't determine why or how to fix it ==== | ||
+ | |||
+ | It is possible that the downloaded code has been corrupted, or outdated. This can be remedied by performing a clean build. | ||
+ | |||
+ | <code bash> | ||
+ | make < | ||
+ | </ | ||
+ | |||
+ | ==== A package no longer exists at its previous URL address/I get a 404 error ==== | ||
+ | |||
+ | This can be temporarily worked around by finding the culprit package and downloading it manually to the '' | ||
+ | |||
+ | < | ||
+ | batocera.linux/ | ||
+ | └─ dl/ | ||
+ | | ||
+ | └─ xa-2.3.11.tar.gz | ||
+ | </ | ||
+ | |||
+ | This can also happen when switching to a brand new Batocera version that you are compiling for x86_64. There is a rather large wine/wow64 package, '' | ||
+ | |||
+ | ==== When compiling under Docker, sometimes wget hangs with no response ==== | ||
+ | |||
+ | This can happen if the MTU inside Docker isn't aligned with the MTU of your system. Check the **mtu** values of the host system network interface and the docker interface, through '' | ||
+ | |||
+ | For example, if you have a Wiregard interface, it can have a lower MTU than the default 1500 value. Let's say you have a Wiregard interface with an MTU value of 1420: then you need to put the Docker MTU at the same value by editing/ | ||
+ | |||
+ | < | ||
+ | { | ||
+ | " | ||
+ | } | ||
+ | </ | ||
+ | |||
+ | ==== After compilation a bunch of .po files get modified, I didn't touch them! ==== | ||
+ | |||
+ | This can happen if someone merged the master branch without first compiling, meaning the PO files get outdated. They are updated once compilation is run. It's usually safe to ignore these, if your addition has no new strings then feel free to discard all '' | ||
+ | |||
+ | However, one caveat, if master has been merged without being compiled, new strings were added //and// a translator was really on point and has already provided a translated line for it, then your updated PO file would overwrite their translated line. In this specific situation, it's no longer "feel free to discard" | ||
+ | |||
+ | ==== My build completes successfully, | ||
+ | |||
+ | If there were no version changes to the package, and the folder for it exists in '' | ||
+ | |||
+ | For instance, if you've added a new system which involved edits to '' | ||
+ |
- compile_batocera.linux.1596204499.txt.gz
- Last modified: 4 years ago
- by ordovice