- Apr 05, 2017
-
-
Arnout Vandecappelle authored
Signed-off-by:
Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by:
Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
-
James Balean authored
Similaly to Linux, this patch adds the ability to copy in and build out-of-source device tree sources during a U-Boot build. Signed-off-by:
James Balean <james@balean.com.au> Cc: Arnout Vandecappelle <arnout@mind.be> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Signed-off-by:
-
Matthias Fritzsche authored
Signed-off-by:
Matthias Fritzsche <txt.file@txtfile.eu> Signed-off-by:
-
Thomas Petazzoni authored
In preparation for the addition of more patches to the syslinux package, reformat the two existing patches as proper Git formatted patches. Signed-off-by: -
Thomas De Schampheleire authored
copy_toolchain_lib_root handles symlinks by recreating them, disregarding the original destination and assuming the destination is in the same directory as the link itself. When a library link points to the real library file in another directory, for example: usr/lib/octeon2/libcrypt.so -> ../../../lib32/octeon2/libcrypt.so.1 then the link created by copy_toolchain_lib_root is broken. It is more robust to copy the symlink to keep the destination intact. The destination path should be present, possibly through other symbolic links. Signed-off-by:Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by:
-
Thomas De Schampheleire authored
The input to copy_toolchain_lib_root is not one library, not a list of libraries, but a library name pattern with glob wildcards. This pattern is then passed to 'find' to get the actual list of libraries matching the pattern. Reflect this using an appropriate variable name. Note: if the root of the buildroot tree contains a file matching one of these library patterns, the copying of libraries from staging to target will not be correct. It is not impossible to fix that, e.g. using 'set -f', but maybe it's not worth it. Signed-off-by:
-
Thomas De Schampheleire authored
copy_toolchain_lib_root has slightly different logic depending on the type of library object: file or link. All actions related to links are not relevant in case you are working with a file. Hence, try to increase clarity by not executing unnecessary lines in the 'file' case. Signed-off-by:
-
Thomas De Schampheleire authored
Signed-off-by:
-
Thomas De Schampheleire authored
A previous commit rewrote broken symbolic links in staging, caused by a non-singular ARCH_LIB_DIR. In this case, the symbolic links are typically using one or more intermediate directory symlinks, which can be simplified using the newly introduced simplify_symlink helper. Signed-off-by:
-
Thomas De Schampheleire authored
The external toolchain logic flattens the directory layout in the staging directory. Regardless of the number of levels present in the extracted toolchain, libraries are always copied to lib/ and usr/lib/, and directory symbolic links are provided to make the original paths available as well. Due to this, the same library may be reachable through a number of paths: one path without any symbolic link, and one or more paths using directory symlinks. Using a direct path in a symlink destination is generally preferred because it is clearer, but it is also more robust against accidental removal of an intermediate directory symlink. Introduce a helper function to simplify a symlink's destination to such a direct path. This function will be used in a subsequent patch. Signed-off-by:
-
Thomas De Schampheleire authored
The toolchain from the Cavium Octeon SDK has a sysroot layout as follows: ./lib32 ./lib32/octeon2 ./lib32-fp ./lib64 ./lib64/octeon2 ./lib64-fp ./usr ./usr/lib ./usr/lib32 ./usr/lib32/octeon2 ./usr/lib32-fp ./usr/lib64 ./usr/lib64/octeon2 ./usr/lib64-fp ./usr/bin ./usr/bin32 ./usr/bin32-fp ./usr/bin64-fp ./usr/libexec ./usr/libexec32 ./usr/libexec32-fp ./usr/libexec64-fp ./usr/sbin ./usr/sbin32 ./usr/sbin32-fp ./usr/sbin64-fp ./usr/include ./usr/share ./sbin ./sbin32 ./sbin32-fp ./sbin64-fp ./etc ./var with the following selections: - lib64 : default - lib64/octeon2 : -march=octeon2 - lib64-fp : -march=octeon3 - lib32 : -mabi=n32 - lib32/octeon2 : -mabi=n32 -march=octeon2 - lib32-fp : -mabi=n32 -march=octeon3 In case of '-mabi=n32 -march=octeon2' (but same is true for n64+octeon2)the original Buildroot toolchain logic would copy both the libraries in lib32 as the subdirectory lib32/octeon2, which means that every library is installed twice (but only one of each is really needed). While ARCH_LIB_DIR is determined by the location of libc.a, which in this case is effectively: <sysroot>/usr/lib32/octeon2/libc.a the variable only retains 'lib32' and not 'lib32/octeon2' as expected. To make Buildroot cope with this style of toolchain layout, we need to adapt the calculation of ARCH_LIB_DIR to also include the second part. This, in turn, means that ARCH_LIB_DIR is no longer guaranteed to be a singular path component, resulting in some additional changes. Certain older Linaro toolchains actually had the same layout. Libraries were located in lib/<tuple> rather than lib directly. Previously, this was handled by adding a toolchain-specific fixup that creates a symlink lib/<tuple> -> lib, but with this patch this would no longer be needed. Note that one difference with the Octeon case is that these Linaro toolchains are not actually multilib, i.e. there is just one location with the libraries and thus there is no problem with duplicated libraries. Signed-off-by: -
Thomas De Schampheleire authored
The helper function copy_toolchain_sysroot has some logic to transform a path into a number of '../' components based on the depth of that path. As this same logic will be needed in another place in a subsequent patch, extract it into a separate helper relpath_prefix. Signed-off-by:
-
Thomas De Schampheleire authored
Normally, the Buildroot toolchain logic copies all required libraries from the external toolchain to the staging directory, including the dynamic loader ld-*.so. There are cases, however, where the dynamic loader is _not_ automatically copied to staging. This happens when the dynamic loader is not inside ARCH_LIB_DIR itself (e.g. lib64), but instead resides in 'lib' (assume, of course, that ARCH_LIB_DIR != 'lib'). Currently, this is fixed in a toolchain-specific fixup, e.g. by recreating a missing symlink or copying over a missing file. Such toolchain specific fixups are not very nice. Moreover, in a subsequent patch, the value of ARCH_LIB_DIR changes for some toolchains, causing them to have the same problem of a missing dynamic loader. This used to be the case for older Linaro toolchains with libraries in 'lib/<tuple>': Buildroot used to set ARCH_LIB_DIR=lib but the mentioned patch changes it to 'lib/<tuple>' instead. As a result, the files directly under 'lib/' will no longer be copied. There should be none, but the dynamic loader is a notable exception. [Note: support for these older Linaro toolchain has been removed in 2016.11] Instead, copy over the ld.so file(s)/link(s) from the extracted toolchain into staging, in the central copy_toolchain_sysroot function. The existing toolchain logic will then handle the copy of these files from staging to target. This means the toolchain-specific fixups can be removed. Signed-off-by:
-
Thomas De Schampheleire authored
The copy_toolchain_sysroot helper features a complex rsync loop that copies various directories from the extracted toolchain to the staging directory. The complexity mainly stems from the fact that we support multilib toolchain tarballs but only copy one of the multilib variants into staging. Increase understandability of this logic by explicitly restricting the rsync excludes to the iteration of the for loop they are relevant for. Additionally, update the function comment. Note: all attempts to reduce duplication between both rsync while keeping things nice and readable failed. One has to be extremely careful regarding line continuation, indentation, and single vs double quoting. In the end, a split up rsync seemed most clean. Signed-off-by:
-
Benoît Allard authored
Signed-off-by:
Benoît Allard <benoit.allard@greenbone.net> Signed-off-by:
-
- Apr 04, 2017
-
-
Bartosz Golaszewski authored
I'm no longer with BayLibre. Change my address to an active one. Signed-off-by:
Bartosz Golaszewski <brgl@bgdev.pl> Signed-off-by:
-
Dagg Stompler authored
This reverts commit e2ac546c. Signed-off-by:
Dagg Stompler <daggs@gmx.com> Signed-off-by:
-
Dagg Stompler authored
Upstream has updated the OpenGL headers (https://github.com/mdrjr/c2_mali/issues/1) it should fix failures such as: http://autobuild.buildroot.net/results/ed8d562ae5fdb472a83f9a07b2f755c80c972c34/ in addition, when the framebuffer variant (i.e not X11) is used, we update the cflags in egl.pc to pass -DMESA_EGL_NO_X11_HEADERS so that X11 headers are not included. Reported-by:
-
Thomas Petazzoni authored
The latest bump of uClibc-ng 1.0.23 contains a commit touching <fcntl.h> that causes a large number of build failures related to time structures. For the moment, let's revert this patch to avoid the build failures. Fixes: http://autobuild.buildroot.net/results/fcd024f6658890861fd7165e15edc65f77a9d8e7/ http://autobuild.buildroot.net/results/431135d9f985f3b3f935cc29fe16728b2412dd3a/ Signed-off-by:
-
Matt Weber authored
With the bump to version 2.6, the following commit needs to be taken into consideration for overloading paths. https://github.com/SELinuxProject/selinux/commit/8162f10e670da963eb65ccf1e7de69ea85aba30d The PYLIBVER is no longer used and the PYTHONLIBDIR is renamed to PYSITEDIR with slightly different pathing. More details can be found in the issue ticket which was marked as a non-issue after analysis that a Buildroot fix was the resolution. https://github.com/SELinuxProject/selinux/issues/51 Signed-off-by:
Matthew Weber <matthew.weber@rockwellcollins.com> Signed-off-by:
-
Vicente Olivert Riera authored
Signed-off-by:
Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by:
-
Vicente Olivert Riera authored
Signed-off-by:
-
Vicente Olivert Riera authored
Signed-off-by:
-
Vicente Olivert Riera authored
Signed-off-by:
-
Vicente Olivert Riera authored
Signed-off-by:
-
Paul Cercueil authored
Add a patch cherry-picked from the upstream libiio project. Fixes: http://autobuild.buildroot.net/results/595/595dfd7a17e2bba71844536c9071f7608879e319 http://autobuild.buildroot.net/results/693/69390ba1f7b1460c3217ef88125faeeeda445f20 http://autobuild.buildroot.net/results/71e/71ecc80e891a36305b3dacbd12bf8130fe4fd31f http://autobuild.buildroot.net/results/4d1/4d1d798ac740403e814b843083b14c9a890dfd54 http://autobuild.buildroot.net/results/00f/00ffdfce0e7780a0f5a5dfadf6bfd63e51c7bbb8 http://autobuild.buildroot.net/results/863/863fa72f443c45793df4837992c5c8dc65590c48 Signed-off-by:
Paul Cercueil <paul.cercueil@analog.com> Signed-off-by:
-
Thomas Petazzoni authored
The libav version built into the gst-ffmpeg code produces a bogus binary on SPARC, which causes the following error of the check-bin-arch script: ERROR: architecture for ./usr/lib/gstreamer-0.10/libgstffmpeg.so is Sparc v8+, should be Sparc ERROR: architecture for ./usr/lib/gstreamer-0.10/libgstpostproc.so is Sparc v8+, should be Sparc ERROR: architecture for ./usr/lib/gstreamer-0.10/libgstffmpegscale.so is Sparc v8+, should be Sparc The problem is the following bit of code in gst-lib/ext/libav/configure: elif enabled sparc; then enabled vis && check_asm vis '"pdist %f0, %f0, %f0"' -mcpu=ultrasparc && add_cflags -mcpu=ultrasparc -mtune=ultrasparc I.e, it checks if the architecture supports the pdist instruction... but forces -mcpu to ultrasparc while doing so. So it's like "let's see if this Ultrasparc instruction exists when I force the compiler to think I'm using Ultrasparc", which is non-sensical. This has been fixed later on in libav upstream: https://git.libav.org/?p=libav.git;a=commit;h=6aa93689abe8c095cec9fa828c2dee3131008995 However, this commit cannot be backported as-is since the shell function check_inline_asm did not exist in the old libav version bundled in gst-ffmpeg. Therefore, we take the simpler route of disabling the VIS optimizations on SPARCv8 and Leon3. Fixes: http://autobuild.buildroot.net/results/e82d179c3d4f92ad7423693a4b1d42379a3f5411/ Signed-off-by:
-
- Apr 03, 2017
-
-
Thomas Petazzoni authored
This reverts commit a6afa968, which causes too many different build issues: http://autobuild.buildroot.net/results/d5c/d5ced6c9738b285e6fda8c3d41c3c66ee0cf1edc/build-end.log http://autobuild.buildroot.net/results/fca/fca01cc5ce13384df0a7f8fad75e2acd05598f99/build-end.log http://autobuild.buildroot.net/results/f17/f1755f26a3eacd84de9bd901b214a5bbb964988c/build-end.log Signed-off-by:
-
Yann E. MORIN authored
We currently have two patches that address the ln --relative issue differently. The first one changes the behaviour to generate absolute symlinks, which is incorrect; the second provides an ad-hoc solution for a single case. Replace both of them with a single patch that mimics ln --relative when the host ln does not support it. Signed-off-by:
"Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com> Signed-off-by:
-
Waldemar Brodkorb authored
The upstream tarball isn't available, no releases since ten years. The latest change to upstream git is from 2014. Better use rpcbind for any RPC portmapper service. Signed-off-by:
Waldemar Brodkorb <wbx@openadk.org> [Thomas: make the legacy option select rpcbind, as suggested by Arnout.] Signed-off-by:
-
Thomas Petazzoni authored
Now that we have switched to binutils 2.27 as the default binutils version, it's time to get rid of binutils 2.25. So this commit remove the 2.25 version choice, the hash file entry, the patches, and adds a Config.in.legacy option. Signed-off-by: -
Thomas Petazzoni authored
Now that binutils 2.28 is available, switch to binutils 2.27 as the default version, for both the host variant and the target variant. Note that the target variant, when no host variant is built, was still 2.25.1: we forgot to update it to 2.26 when the host version was updated to 2.26. Signed-off-by: -
Thomas Petazzoni authored
Commit d8878112 ("binutils: remove deprecated 2.24.X") removed support for binutils 2.24, but forgot to remove the hash from binutils.hash. This commit fixes that. Signed-off-by:
-
Adam Duskett authored
- Patch 0100-elf32-arm-no-data-fix.patch is upstream as of commit 6342be709e8749d0a44c02e1876ddca360bfd52f, so it is removed. - Patch 0130-tc-xtensa.c-fixup-xg_reverse_shift_count-typo.patch is upstream as of commit 78fb7e37eb8bb08ae537d6c487996ff17c810332, so it is removed. - Patch 0900-Revert-part-Set-dynamic-tag-VMA-and-size-from-dynami.patch is upstream as of commit c646b02fdcae5f37bd88f33a0c4683ef13ad5c82, so it is removed. - All other patches are kept, just refreshed to apply cleanly on the new binutils version. Signed-off-by:
Adam Duskett <Adamduskett@outlook.com> [Thomas: improve commit log.] Signed-off-by:
-
Waldemar Brodkorb authored
Bugfix release, internal RPC implementation removed. All patches applied upstream. Signed-off-by:
-
Peter Seiderer authored
Fixes [1]: .../uhttpd-a8bf9c00842224edb394e79909053f7628ee6a82/listen.c: In function 'uh_setup_listeners': .../uhttpd-a8bf9c00842224edb394e79909053f7628ee6a82/listen.c:120:30: error: 'TCP_FASTOPEN' undeclared (first use in this function) [1] http://autobuild.buildroot.net/results/56e/56e0727ccd1255b05e03d1b79dc238bd88701230 Signed-off-by:
Peter Seiderer <ps.report@gmx.net> Signed-off-by:
-
Rodrigo Rebello authored
Because dc3dd is being autoreconfigured and comes with an old gettext infra, gettextize needs to be called so that the infra is updated to match the newer version used in Buildroot. Commit b36d57fa included a patch to add the definition of MKDIR_P to po/Makefile.in.in in order to fix autobuild failures that ocurred when host-gettext was built before dc3dd. This patch is no longer necessary as gettextize adds a new Makefile template which contains the needed definition, so drop it. Signed-off-by:
Rodrigo Rebello <rprebello@gmail.com> Signed-off-by:
-
Rahul Bedarkar authored
python-serial is provided under BSD-3-Clause license. Signed-off-by:
Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by:
-
Rahul Bedarkar authored
Signed-off-by:
-
Rahul Bedarkar authored
LICENSE file refers to PHP license version 3.01 Signed-off-by:
-
