support/test-pkg: print number of toolchains and progress
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas De Schampheleire <patrickdepinguin@gmail.com> Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Our patch adding nios2 support to libnspr uses the built-in compiler
define "nios2". However, this doesn't work with C++11, where only the
__nios2__ define is available. Since __nios2__ is always available,
use that instead:
Patch 0001-nios2.patch is therefore changed to use __nios2__ (the rest
of the change noise is due to using quilt to format the patch). Patch
0002-microblaze.patch is simply updated to apply correctly on top of
the modified 0001-nios2.patch.
This fixes the build of the poppler library on nios2. It is built with
-std=c++11, and includes nspr headers (through nss), causing a build
issue.
toolchain: copy_toolchain_lib_root: copy symlinks instead of recreating them
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 Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
toolchain-external: clarify rsync excludes in copy_toolchain_sysroot
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: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.petazzoni@free-electrons.com> Signed-off-by: Dagg Stompler <daggs@gmx.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
uclibc: add patch fixing build failures related to time structures
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.
Matt Weber [Tue, 4 Apr 2017 02:06:11 +0000 (21:06 -0500)]
libselinux: query for python site-packages dir directly
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Thomas Petazzoni [Wed, 22 Mar 2017 23:04:56 +0000 (00:04 +0100)]
gst-ffmpeg: work-around bogus configure logic on SPARC
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:
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.
package/systemd: better patch to avoid ln --relative
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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 <thomas.petazzoni@free-electrons.com>
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 <thomas.petazzoni@free-electrons.com>
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 <thomas.petazzoni@free-electrons.com>
Commit d8878112ad3df2a3d9468cf40a2401b581e7e432 ("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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
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 b36d57fab 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: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
LICENSE file refer to PHP license version 3.01. License header in all
source files refer to PHP license version 3.01 except source files for
fastlz library which is provided under MIT license and g_fmt.{c,h}
which has ISC-like license header.
Signed-off-by: Rahul Bedarkar <rahulbedarkar89@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
package/tyrian: fixes compilation with static libs
Has been tested with: "./support/scripts/test-pkg -c tyrian.cfg -p opentyrian" Fixes: http://autobuild.buildroot.net/results/0e2345db82b33f591958fc0f72ad914adafe0522
and some similar previous build failure.
Thanks Thomas for the tip ;-).
Signed-off-by: Julien BOIBESSOT <julien.boibessot@armadeus.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Autoreconf is not necessary anymore after a fix was commit upstream:
https://github.com/01org/intel-vaapi-driver/commit/fe6280841dfaaee94e8664517420f351cd334c86
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
package/synergy: bump to version 1.8.8 to fix build errors
Building synergy on sparc, nios2, mipsel and mips64el would fail with
the following errors:
src/lib/ipc/IpcClientProxy.cpp: In member function 'void IpcClientProxy::send(const IpcMessage&)':
src/lib/ipc/IpcClientProxy.cpp:150:59: error: ISO C++ says that these are ambiguous, even though the worst conversion for the first is better than the worst conversion for the second: [-Werror]
ProtocolUtil::writef(&m_stream, kIpcMsgLogLine, &logLine);
^
In file included from src/lib/ipc/IpcClientProxy.cpp:23:0:
src/lib/ipc/../synergy/ProtocolUtil.h:82:16: note: candidate 1: static void ProtocolUtil::writef(void*, const char*, va_list)
static void writef(void*, const char* fmt, va_list);
^
src/lib/ipc/../synergy/ProtocolUtil.h:53:16: note: candidate 2: static void ProtocolUtil::writef(synergy::IStream*, const char*, ...)
static void writef(synergy::IStream*,
^
src/lib/ipc/../synergy/ProtocolUtil.h:82:16: error: 'static void ProtocolUtil::writef(void*, const char*, va_list)' is private
static void writef(void*, const char* fmt, va_list);
^
src/lib/ipc/IpcClientProxy.cpp:150:59: error: within this context
ProtocolUtil::writef(&m_stream, kIpcMsgLogLine, &logLine);
^
At global scope:
cc1plus: error: unrecognized command line option '-Wno-unused-local-typedef' [-Werror]
cc1plus: all warnings being treated as errors
Fabrice Fontaine [Sun, 12 Feb 2017 20:26:56 +0000 (21:26 +0100)]
libmaxminddb: new package
C library for the MaxMind DB file format
The libmaxminddb library provides a C library for reading
MaxMind DB files, including the GeoIP2 databases from MaxMind.
This is a custom binary format designed to facilitate fast
lookups of IP addresses while allowing for great flexibility
in the type of data associated with an address.
The MaxMind DB format is an open format. The spec is available
at http://maxmind.github.io/MaxMind-DB/. This spec is licensed
under the Creative Commons Attribution-ShareAlike 3.0 Unported
License.
http://maxmind.github.io/libmaxminddb
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
[Thomas: add entry in DEVELOPERS file.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
When dieharder was committed, Thomas removed the hook to cleanup the m4
files, on the reason that autoreconf would recreate the broken symlinks
(and because the hook was too complex).
It turns out the hook was needed: if the symbolic links are
broken (libtool not installed on the host machine), autoreconf fails to
do its job.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Cc: Julien Viard de Galbert <julien@vdg.name> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Julien Viard de Galbert <julien@vdg.name> Reviewed-by: Romain Naour <romain.naour@gmail.com>
[Thomas:
- remove complicated DIEHARDER_POST_PATCH_FIXUP that replaces bogus
libtool .m4 files: since we are anyway autoreconfiguring the
package, this is not necessary. And therefore, remove host-libtool
in the dependencies.
- use GPL-2.0 instead of GPLv2
- add entry in DEVELOPERS file.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Carlos Santos [Wed, 1 Feb 2017 17:51:08 +0000 (15:51 -0200)]
python-lxml: allow build as host package
While currently there is no in-tree Buildroot package which depends on
host-python-lxml, we (DATACOM) have some proprietary modules that use it
in their test scripts.
We tested python-lxml as host package and confirmed that it builds and
works correctly. Someone else might require it, so we are proposing its
inclusion.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
[Thomas: add Config.in.host entry.] Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Jérôme Pouiller [Tue, 20 Dec 2016 13:46:27 +0000 (14:46 +0100)]
python3: remove full path from .pyc
.pyc files include path to source .py file. This patch changes the way
`pycompile.py' is launched in order to only keep the part relative to
$TARGET_DIR.
This work was sponsored by `BA Robotic Systems'.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Jérôme Pouiller [Tue, 20 Dec 2016 13:46:26 +0000 (14:46 +0100)]
python2: remove full path from .pyc
.pyc files include path to source .py file. This patch changes the way
`pycompile.py' is launched in order to only keep the part relative to
$TARGET_DIR.
This work was sponsored by `BA Robotic Systems'.
Signed-off-by: Jérôme Pouiller <jezz@sysmic.org> Reviewed-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be> Reviewed-by: Samuel Martin <s.martin49@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Adam Duskett [Tue, 21 Mar 2017 00:53:37 +0000 (20:53 -0400)]
ncurses: bump to 6.0
ncurses 6.0 has been out for a while now (August 8th 2015!), so this
patch brings us up to the latest version.
- The first patch is no longer needed as it was fixed in the new
release.
- The other two packages are still applicable, so they have been
updated to apply properly on the new ncurses version.
- A new option: --with-pkg-config-libdir has been added. Without it
pkg files wouldn't install to the correct location.
- NCURSES_ABI_VERSION is no longer needed, as there is only 6.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
projects / coffee / buildroot.git / log