9bb7d10eea
In some cases, upstream just update their releases in-place, without renaming them. When that package is updated in Buildroot, a new hash to match the new upstream release is included in the corresponding .hash file. As a consequence, users who previously downloaded that package's tarball with an older version of Buildroot, will get stuck with an old archive for that package, and after updating their Buildroot copy, will be greeted with a failed download, due to the local file not matching the new hashes. Also, an upstream would sometime serve us HTML garbage instead of the actual tarball we requested, like SourceForge does from time for as-yet unknown reasons. So, to avoid this situation, check the hashes prior to doing the download. If the hashes match, consider the locally cached file genuine, and do not download it. However, if the locally cached file does not match the known hashes we have for it, it is promptly removed, and a download is re-attempted. Note: this does not add any overhead compared to the previous situation, because we were already checking hashes of locally cached files. It just changes the order in which we do the checks. For the records, here is the overhead of hashing a 231MiB file (qt-everywhere-opensource-src-4.8.6.tar.gz) on a core-i5 @2.5GHz: cache-cold cache-hot sha1 1.914s 0.762s sha256 2.109s 1.270s But again, this overhead already existed before this patch. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Peter Korsgaard <jacmet@uclibc.org> Cc: Gustavo Zacarias <gustavo@zacarias.com.ar> Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> |
||
---|---|---|
arch | ||
board | ||
boot | ||
configs | ||
docs | ||
fs | ||
linux | ||
package | ||
support | ||
system | ||
toolchain | ||
.defconfig | ||
.gitignore | ||
CHANGES | ||
Config.in | ||
Config.in.legacy | ||
COPYING | ||
Makefile | ||
Makefile.legacy | ||
README |
To build and use the buildroot stuff, do the following: 1) run 'make menuconfig' 2) select the packages you wish to compile 3) run 'make' 4) wait while it compiles 5) Use your shiny new root filesystem. Depending on which sort of root filesystem you selected, you may want to loop mount it, chroot into it, nfs mount it on your target device, burn it to flash, or whatever is appropriate for your target system. You do not need to be root to build or run buildroot. Have fun! Offline build: ============== In order to do an offline-build (not connected to the net), fetch all selected source by issuing a $ make source before you disconnect. If your build-host is never connected, then you have to copy buildroot and your toplevel .config to a machine that has an internet-connection and issue "make source" there, then copy the content of your dl/ dir to the build-host. Building out-of-tree: ===================== Buildroot supports building out of tree with a syntax similar to the Linux kernel. To use it, add O=<directory> to the make command line, E.G.: $ make O=/tmp/build And all the output files (including .config) will be located under /tmp/build. More finegrained configuration: =============================== You can specify a config-file for uClibc: $ make UCLIBC_CONFIG_FILE=/my/uClibc.config And you can specify a config-file for busybox: $ make BUSYBOX_CONFIG_FILE=/my/busybox.config To use a non-standard host-compiler (if you do not have 'gcc'), make sure that the compiler is in your PATH and that the library paths are setup properly, if your compiler is built dynamically: $ make HOSTCC=gcc-4.3.orig HOSTCXX=gcc-4.3-mine Depending on your configuration, there are some targets you can use to use menuconfig of certain packages. This includes: $ make HOSTCC=gcc-4.3 linux-menuconfig $ make HOSTCC=gcc-4.3 uclibc-menuconfig $ make HOSTCC=gcc-4.3 busybox-menuconfig Please feed suggestions, bug reports, insults, and bribes back to the buildroot mailing list: buildroot@buildroot.org