In commit b0f025386f a patch was added
to make sure that python-numpy does work in uClibc. This patch was
needed for the x86 architecture, because uClibc in fact does support
fenv for x86. However, we don't turn on this support in our uClibc
config. Because the Config.in depends still allowed uClibc for x86,
this lead to a built failure, which lead to the fix in commit b0f02538.
But since this fix also fixes it for all other (supported)
architectures, we can just remove the !uClibc dependency completely.
This is also propagated to the reverse dependency in opencv3.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Gwenhael Goavec-Merou <gwenhael.goavec-merou@trabucayre.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
nfs-utils has been patched to install only the needed systemd unit files
supported.
Also tmpfiles was needed because the folder /run/nfs is a tmpfs
and nfs-utils need some files to be there to work correctly.
Signed-off-by: Aurélien Chabot <aurelien@chabot.fr>
[Maxime: Remove patches included originally in the patch as they have
have been merged upstream in v1.3.3]
Signed-off-by Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
[Thomas:
- add comment in nfs-utils_env.sh to explain why an empty script is
needed.
- remove incorrect indentation.]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
We're disabling fenv.h usage on i386 because it is not available in
musl/uclibc (and not musl/glibc as was written).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The official upstream site is available again, so let's switch to
using it.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Reviewed-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Tested-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that xtensa toolchain is able to compile huge functions this
workaround is no longer needed.
This reverts commit d21932508e.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
With support from assembler this option allows compiling huge functions,
where single literal pool at the beginning of a function may not be
reachable by L32R instructions at its end.
Currently assembler --auto-litpools option cannot deal with literals
used from multiple locations separated by more than 256 KBytes of code.
Don't turn constants into literals, instead use MOVI instruction to load
them into registers and let the assembler turn them into literals as
necessary.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Auto-litpools is the automated version of text-section-literals: literal
pool candidate frags are planted every N frags and during relaxation
they are turned into actual literal pools where literals are moved to
become reachable for their first reference by L32R instruction.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
One of the gcc configure options that we hash for ccache is
--with-pkgversion which is set to something like Buildroot
2015.11-git-00426-ge7e7e4f - i.e., it will change with every buildroot
commit. That's obviously not wanted, so substitute this away.
Also add a \n to the printf so the output is a bit more readable.
[Peter: update documentation to match]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
When building in a different output directory than the original build,
there will currently be a lot of ccache misses because in many cases
there is some -I/... absolute path in the compilation. Ccache has an
option CCACHE_BASEDIR to substitute absolute paths with relative paths,
so they wil be the same in the hash (and in the output).
Since there are some disadvantages to this path rewriting, it is made
optional as BR2_CCACHE_USE_BASEDIR. It defaults to y because the
usefulness of ccache is severely reduced without this option.
In addition to CCACHE_BASEDIR, we also substitute away the occurences
of $(HOST_DIR) in the calculation of the compiler hash. This is done
regardless of the setting of BR2_CCACHE_USE_BASEDIR because it's
quite harmless.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Our current ccache disables hashing of the compiler executable itself,
because using the default 'mtime' doesn't work in buildroot: we always
rebuild the compiler, so the mtime is always different, so the cache
always misses.
However, in the current situation, if a user changes the compiler
configuration (which would result in the compiler generating different
object files than before) and does 'make clean all', ccache may in fact
reuse object files from the previous run. This rarely gives problems,
because
(1) the cache expires quite quickly (it's only 1GB by default),
(2) radically changing compiler options will cause cache misses because
different header files are used,
(3) many compiler changes (e.g. changing -mtune) have little practical
effect because the resulting code is usually still compatible,
(4) we currently don't use CCACHE_BASEDIR, and almost all object files
will contain an absolute path (e.g. in debug info), so when
building in a different directory, most of it will miss,
(5) we do mostly build test, and many of the potential problems only
appear at runtime.
Still, when ccache _does_ use the wrong cached object files, the
effects are really weird and hard to debug. Also, we want reproducible
builds and obviously the above makes builds non-reproducible. So we
have a FAQ entry that warns against using ccache and tells the user to
clear the cache in case of problems.
Now that ccache is called from the toolchain wrapper, it is in fact
possible to at least use the 'mtime' compiler hash for the external
toolchain and for the host-gcc. Indeed, in this case, the compiler
executable comes from a tarball so the mtime will be a good reference
for its state. Therefore, the patch (sed script) that changes the
default from 'mtime' to 'none' is removed.
For the internal toolchain, we can do better by providing a hash of
the relevant toolchain options. We are only interested in things that
affect the compiler itself, because ccache also processes the header
files and it doesn't look at libraries because it doesn't cache the
link step, just compilation. Everything that affects the compiler
itself can nicely be summarised in $(HOST_GCC_FINAL_CONF_OPTS). Of
course, also the compiler source itself is relevant, so the source
tarball and all the patches are included in the hash. For this purpose,
a new HOST_GCC_XTENSA_OVERLAY_TAR is introduced.
The following procedure tests the ccache behaviour:
Use this defconfig:
BR2_arm=y
BR2_CCACHE=y
make
readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"
Now make menuconfig, change variant into BR2_cortex_a9
make clean; make
readelf -A output/build/uclibc-1.0.6/libc/signal/signal.os
-> Tag_CPU_name: "ARM926EJ-S"
should be "Cortex-A9"
After this commit, it is "Cortex-A9".
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Cc: Samuel Martin <s.martin49@gmail.com>
Cc: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Although this patch is still relevant for upstream, we don't need it
anymore in buildoort because we no longer have _ARG1.
Note that it would be relevant again if we would add host-qpid-proton.
However, the 0.10 release already has the fix.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
All the complexity with the different ways that CMAKE_C_COMPILER and
CMAKE_C_COMPILER_ARG1 can be set are no longer needed, it's all handled
by the toolchain wrapper now.
Note that it is still necessary to handle this for the host build.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now the ccache handling has moved to the toolchain wrapper, it is no
longer necessary to pass TARGET_CC_NOCCACHE.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since we always have a toolchain wrapper now, we can move the ccache
call to the toolchain wrapper.
The hostcc ccache handling obviously stays.
The global addition of ccache to TARGET_CC/CXX is removed, but many
individual packages and infras still add it. This means we have a
chain like this: ccache -> toolchain-wrapper -> ccache -> gcc
However, this is fairly harmless: for cache misses, the inner ccache
just adds overhead and for cache hits, the inner ccache is never
called. Later patches will remove these redundant ccache calls.
As a side effect, perl now supports ccache as well.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Danomi Manchego <danomimanchego123@gmail.com>
Cc: Károly Kasza <kaszak@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Now that the calls to gcc always pass through the toolchain wrapper, it
is no longer necessary to patch gcc to support poisoning.
This does have the disadvantage that there is no unsafe path check for
libc, libgcc and libstdc++ (all of these are built before the wrapper
exists). But we can assume that the toolchain components themselves
should be pretty safe.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
We have a toolchain wrapper for external toolchain, but it is also
beneficial for internal toolchains, for the following reasons:
1. It can make sure that BR2_TARGET_OPTIMIZATION is passed to the
compiler even if a package's build system doesn't honor CFLAGS.
2. It allows us to do the unsafe path check (i.e. -I/usr/include)
without patching gcc.
3. It makes it simpler to implement building each package with a
separate staging directory (per-package staging).
4. It makes it simpler to implement a compiler hash check for ccache.
The wrapper is reused from the external toolchain. A third CROSS_PATH_
option is added to the wrapper: in this case, the real executable is in
the same directory, with the extension .real.
The creation of the simple symlinks is merged with the creation of the
wrapper symlinks, otherwise part of the -gcc-ar handling logic would
have to be repeated.
The complex case-condition could be refactored with the one for the
external toolchain, but then it becomes even more complex because
they each have special corner cases. For example, the internal
toolchain has to handle *.real to avoid creating an extra indirection
after host-gcc-{final,initial}-rebuild.
Instead of creating the .real files, it would also have been possible
to install the internal toolchain in $(HOST_DIR)/opt, similar to what
we do for the external toolchain. However, then we would also have to
copy things to the sysroot and do more of the magic that the external
toolchain is doing. So keeping it in $(HOST_DIR)/usr/bin is much
simpler.
Note that gcc-initial has to be wrapped as well, because it is used for
building libc and we want to apply the same magic when building libc.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Cc: Fabio Porcedda <fabio.porcedda@gmail.com>
Cc: Jérôme Oufella <jerome.oufella@savoirfairelinux.com>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The FOO_SITE/FOO_SOURCE variables usually point to a tarball containing
source code.
For the downloaded external toolchains this is not true, the "source"
tarball actually contains binaries. This is fine for making Buildroot
work, but for legal-info we really want to ship real source code, not
binaries.
Luckily, some (hopefully all) toolchain vendors publish a downloadable
tarball containing the source code counterpart for their binary
packages.
Here we allow the user to declare the URL of this other tarball in the
pair of variables FOO_ACTUAL_SOURCE_TARBALL (by default equal to
FOO_SOURCE) and FOO_ACTUAL_SOURCE_SITE (by default equal to FOO_SITE).
If the "actual source" package can be downloaded from the same
directory as the binary package, then only FOO_ACTUAL_SOURCE_TARBALL
needs to be set.
Note this change is not strictly toolchain-specific: it might be useful
for other packages that happen to ship binaries in the same way.
[Thomas:
- remove "the source code has not been saved" warning that could
never be triggered due to how the conditions were
organized. Discussed with Luca live during the meeting.]
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
----
v2 -> v3:
- Remove the select (not needed, we only have to propagate the
depends on)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Not needed anymore since the URLs have been cleared, the manual states
they are illegal and a check has been introduced to notice future
mistakes.
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
A trailing slash in FOO_SITE is useless, since Buildroot automatically adds
a slash between FOO_SITE and the filename as appropriate.
Moreover it is potentially harmful, which led to introducing a workaround
to strip them:
commit 1cbffbd015
Author: Shawn J. Goff <shawn7400@gmail.com>
Date: Fri Apr 12 09:40:30 2013 +0000
eliminate double slashes caused by FOO_SITE ending in a slash
When a FOO_SITE variable ends in a slash and gets joined with a
FOO_SOURCE variable like $(FOO_SITE)/$(FOO_SOURCE), the resulting URI
has a double slash. While double-slashes are fine in unix paths, they
are reserved in URIs - the part following '//' must be an authority.
So let's ban trailing slashes entirely. They have all been removed in
a 7b0e757fb8, now add a check to error out loudly in case a new one
is added.
Example commands to test this check:
$ make busybox-dirclean busybox-source
rm -Rf /home/murray/devel/buildroot/output/build/busybox-1.23.2
busybox-1.23.2.tar.bz2: OK (md5: 7925683d7dd105aabe9b6b618d48cc73)
busybox-1.23.2.tar.bz2: OK (sha1: 7f37193cb249f27630e0b2a2c6c9bbb7b1d24c16)
$
$ make BUSYBOX_SITE=http://www.busybox.net/downloads/ busybox-dirclean busybox-source
rm -Rf /home/murray/devel/buildroot/output/build/busybox-1.23.2
BUSYBOX_SITE (http://www.busybox.net/downloads/) cannot have a trailing slash
make[1]: *** [/home/murray/devel/buildroot/output/build/busybox-1.23.2/.stamp_downloaded] Error 1
make: *** [_all] Error 2
$
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Cc: Arnout Vandecappelle <arnout@mind.be>
Cc: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The 0001-CMakeLists-add-rules-for-installation.patch patch has been
merged upstream 7 minutes after it was submitted. So let's bump to the
latest upstream version and drop the no longer needed patch.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
ZXing was hosted on Google Code, which is a closing. The current link
was already redirecting to the github repo.
But upstream is no longer supporting the cpp bindings, it's now a Java
library/application.
A fork has been created from the latest cpp source of the original
upstream. So this commit creates a new package, zxing-cpp, and adds
Config.in.legacy handling for the old zxing pakcage that is removed.
[Thomas:
- add a patch that improves the CMakeLists.txt file to add
installation rules. This allows to remove the manual installation
logic from zxing-cpp.mk.
- make libiconv a normal optional dependency. No need to involve
BR2_ENABLE_LOCALE in the condition, since libiconv can only be
enabled when !BR2_ENABLE_LOCALE.
- bump to the latest upstream version.
- add hash file.]
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
FreeRDP does not have a single C++ source file, however it insists on
having a C++ compiler. Removing that requirement is a bit too much
involving, so we just depend on it...
Fixes:
http://autobuild.buildroot.org/results/e5b/e5bee760d52e5ee433dcb6c8a7296f99312cfcf4/
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
FreeRDP uses CMSPAR, which is defined by glibc in bits/termios.h .
glibc has two flavours of bits/termios.h: a genmeric one and an
architecture-specific one. When installing, glibc will install the
architecture-specific file if it exists, otherwise it installs the
generic file. Only Alpha, MIPS, PPC and Sparc have their own
bits/termios.h.
The generic bits/termios.h, as well as the Alpha, PPC and Sparc flavours
do define CMSPAR. However, the MIPS flavour does not define it.
We add a patch to FreeRDP that defines CMSPAR to the value from the
generic value, which is also the value known to the Linux kernel for
MIPS.
Fixes:
http://autobuild.buildroot.org/results/0b4/0b4793f0bf9f4c57933897f3480054a4e06528ad/http://autobuild.buildroot.org/results/7a2/7a2284d0a2987158fa2e78f789b07c8c6fcdb974/http://autobuild.buildroot.org/results/387/3874088c3ccd4bbf76ea0c911ca1ef64c7dc9d1c/
...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Peter Korsgaard <jacmet@uclibc.org>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
And also move to GitHub since Google Code is going to die soon.
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Mesa3d 10.6.x is reaching end-of-life:
http://lists.freedesktop.org/archives/mesa-announce/2015-October/000178.html
"NOTE: It is anticipated that 10.6.9 will be the final release in the
10.6 series. Users of 10.6 are encouraged to migrate to the 11.0 series
in order to obtain future fixes."
Run-time testing with Kodi Isengard on an Intel GPU was positive.
Rebased 0001-Fix-khrplatform.h-not-installed-if-EGL-is-disabled.patch.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Building host-localdef fails under gcc5.1 reporting multiple definitions and undefined references:
argp-help.o: In function `argp_fmtstream_write':
argp-help.c:(.text+0x1dc0): multiple definition of `argp_fmtstream_write'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x750): first defined here
argp-help.o: In function `argp_fmtstream_puts':
argp-help.c:(.text+0x1e10): multiple definition of `argp_fmtstream_puts'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x810): first defined here
argp-help.o: In function `argp_fmtstream_putc':
argp-help.c:(.text+0x1e80): multiple definition of `argp_fmtstream_putc'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x7b0): first defined here
argp-help.o: In function `argp_fmtstream_set_lmargin':
argp-help.c:(.text+0x1ed0): multiple definition of `argp_fmtstream_set_lmargin'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x590): first defined here
argp-help.o: In function `argp_fmtstream_set_rmargin':
argp-help.c:(.text+0x1f00): multiple definition of `argp_fmtstream_set_rmargin'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x5c0): first defined here
argp-help.o: In function `argp_fmtstream_set_wmargin':
argp-help.c:(.text+0x1f30): multiple definition of `argp_fmtstream_set_wmargin'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x5f0): first defined here
argp-help.o: In function `argp_fmtstream_point':
argp-help.c:(.text+0x1f60): multiple definition of `argp_fmtstream_point'
argp-fmtstream.o:argp-fmtstream.c:(.text+0x620): first defined here
charmap.o: In function `cmlr_open.constprop.2':
charmap.c:(.text+0x230a): undefined reference to `charmap_hash'
charmap.o: In function `charmap_read':
charmap.c:(.text+0x2397): undefined reference to `charmap_hash'
locfile.o: In function `locfile_read':
locfile.c:(.text+0x2e4): undefined reference to `locfile_hash'
locfile.c:(.text+0x8f4): undefined reference to `locfile_hash'
locfile.c:(.text+0x9b3): undefined reference to `locfile_hash'
locfile.c:(.text+0xa36): undefined reference to `locfile_hash'
collect2: error: ld returned 1 exit status
Makefile:58: recipe for target 'localedef' failed
Ref: http://permalink.gmane.org/gmane.comp.embedded.ptxdist.devel/12950
Signed-off-by: Stephen Agate <stephen.agate@talktalk.net>
Reviewed-by: Romain Naour <romain.naour@openwide.fr>
Tested-by: Romain Naour <romain.naour@openwide.fr>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
The problem looks like this:
/br/output/host/usr/mipsel-buildroot-linux-uclibc/sysroot/usr//lib/librt.a(timer_routines.os):
In function `__start_helper_thread':
timer_routines.c:(.text+0x2f4): undefined reference to `pthread_atfork'
collect2: error: ld returned 1 exit status
Adding -pthread to LDFLAGS fixes the problem.
Fixes:
http://autobuild.buildroot.net/results/a87/a87a764d3a28f835ed8645923594f7023a662ae8/
Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
'echo -n' is not a POSIX construct (no flag support), we shoud use
'printf', especially in init script.
This patch was generated by the following command line:
git grep -l 'echo -n' -- `git ls-files | grep -v 'patch'` | xargs sed -i 's/echo -n/printf/'
Signed-off-by: Maxime Hadjinlian <maxime.hadjinlian@gmail.com>
Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
[Peter: fix .hash comment as pointed out by Vincent]
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
