If BR2_SHARED_LIBS is set, only install shared version of library
(continue to build both libraries through all target as there is no
libcap.so target but only a libcap.so.$(VERSION).$(MINOR))
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
bump the U-Boot stable version to v2018.11
Tested-by: Shyam Saini <shyam@amarulasolutions.com>
Signed-off-by: Jagan Teki <jagan@amarulasolutions.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
The Buildroot dl-wrapper tries to download
Qt5_CinematicExperience_%22rpi_%221.0.tgz, which fails, so this commit
fixes the archive name by removing useless double quotes.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
libclang.so is statically linking against all LLVM static libraries
instead of linking dynamically against libLLVM.so.
This patch fixes this problem by setting LLVM_LINK_LLVM_DYLIB to ON.
Signed-off-by: Valentin Korenblit <valentin.korenblit@smile.fr>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This bump contains many bug fixes, as well as the following security
issue, patched in Go 1.10.1:
CVE-2018-7187: The "go get" implementation in Go 1.9.4, when the
-insecure command-line option is used, does not validate the import path
(get/vcs.go only checks for "://" anywhere in the string), which allows
remote attackers to execute arbitrary OS commands via a crafted web
site.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Now that we fixed cross-compilation in the go package, cleanup the build
to remove the workaround added in 60c5c96ae1
"package/go: Build host tools with host CC". We only need a single pass
to build the go toolchain.
Signed-off-by: Anisse Astier <anisse@astier.eu>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
For various reasons, we've always suggested users to avoid using a
branch as version string for their packages, because it does not work
as a they would expect:
- it is not reproducible, because the branch may change between two
builds that are done at different times;
- it does not even follow the branch, as Buildroot anyway generates
a local tarball, which it will reuse on subsequent builds.
Furthermore, since we fetch and not pull, any existing local branch
is not updated.
Yet, until recently, using a branch name would just work (with the
above limitations): the git tree was cloned, the branch checked out,
and the tarball created.
But with the advent of the git caching, using a branch name does not
work anymore. Indeed, we now do a git-fetch, and that does not create
a local master branch. So we can't check out master, because it does
not exist locally. And for other branches, as noticed above, the local
branch does not get udpated to the remote one.
Furthermore, the local branches are only created by chance, again as a
side-effect of trying to fetch the "special refs".
So, we can't say that we reliably support the use of a branch name.
Update the manual to state that using a branch does not work. Remove
the 'stable' example, as it looked like the name of a stable branch;
instead, replace it with a version string that ressemble a tag.
Fix the layout of the manual by making the version examples an actual
bulleted list.
Note: the above is only entirely true for git. For Mercurial, CVS and
subversion, the status may be mixed, but nonetheless, using branches is
still a bad idea, if at least because it is not reproducible, and
because Buildroot does not even follow the branch. So, we do not
differentiate between the various SCMs, and just flatly state that using
a branch name is not supported.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Cc: Peter Korsgaard <peter@korsgaard.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
This update includes GA version of the DDR training binaries for i.MX8M.
Signed-off-by: Gary Bisson <gary.bisson@boundarydevices.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
It turns out that mpers support in strace still does not play nicely
with musl libc. As explained in commit 7892a778b (package/strace:
disable libmpers with musl toolchains) headers mixup causes gcc header
to be included, instead of the musl one, resulting in conflicting types.
Commit 1088372941 (strace: bump to version 4.21) incorrectly enabled
mpers for musl. Revert that.
Fixes:
http://autobuild.buildroot.net/results/345/3452419498c074ca66f36f0f87263fa10662ac86/
Cc: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the dahdi firmware files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where dahdi-linux looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: ***** ***** <zyama.abel@mail.ru>
Cc: Carlos Santos <casantos@datacom.ind.br>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Since we reworked the download infra, the location for packages to look
for their files has moved to a per-package directory.
For systems where a download of the asterisk sound files was already
done in a version prior to the rework, all was working fine so far,
because the files were indeed in the main DL directory.
But for systems where the download is first attempted after the rework,
the files are not found (even though they are properly downloaded).
Fix the location where asterisk looks for its extra files.
Reported-by: ***** ***** <zyama.abel@mail.ru>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: ***** ***** <zyama.abel@mail.ru>
Cc: Carlos Santos <casantos@datacom.ind.br>
Cc: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
A person on IRC reported a build failure with the util-linux package,
looking like this:
for I in uname26 linux32 linux64 ; do \
cd /home/aep/consulting/chargery/tracker/output/target/usr/bin && ln -sf setarch $I ; \
done
[...]
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
/bin/sh: line 1: ./ln: cannot execute binary file: Exec format error
The issue was an empty path in the PATH variable, which means "current
working directory", causing a "ln" binary built by util-linux for the
target to be used instead of the system-provided "ln".
We already check a number of things in the PATH and LD_LIBRARY_PATH
variables in support/dependencies/dependencies.sh, but we were not
checking that PATH did not contain an empty path.
This commit fixes that and takes this opportunity to simplify the test
code for PATH and LD_LIBRARY_PATH.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
[Thomas: improve commit log.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
- Add some explanations about the Blackfin removal, as suggested by
Yann E. Morin.
- Add list of resolved issues.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
