Cleanup the libcgi package,
by using https://github.com/rafaelsteil/libcgi as an upstream.
Remove old patch and use cmake to build new version.
Signed-off-by: Joe Lin <xlcwu.taiwan@gmail.com>
[Mario:
- Use github URL in Config.in
- Use upstream sha256 hash]
Signed-off-by: Mario J. Rugiero <mrugiero@gmail.com>
[Arnout:
- Add reference to upstream hash file
- Remove unneeded LIBCGI_SUPPORTS_IN_SOURCE_BUILD = NO]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This patch bumps to mono 5.0.1.1 and updates the unit tests patch
accordingly.
The latest version of mono carries a bit of changes in the monolite
package: the version string changes and from now on, monolite should
be installed in a subdirectory with the exact version string as a name.
Therefore, mono and monolite are bumped in a single commit.
Patch 0004, although applied in upstream master, is not yet in this
(stable) release.
Signed-off-by: Angelo Compagnucci <angelo.compagnucci@gmail.com>
[Arnout: squashed the patches, removed /usr part from HOST_DIR]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Removed 0003-Use-gnu-11-standard-to-prevent-errors-on-PPC.patch, since
stella now uses -std=c++14 that builds fine when using PPC altivec
vectorization.
Removed 0004-gcc7.patch, backported from upstream.
Update toolchain dependencies to gcc 4.9 since codebase now uses C++14 features.
Signed-off-by: Sergio Prado <sergio.prado@e-labworks.com>
[Arnout: also remove 0004-gcc7.patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Switched to github helper because upstream does not provide the tarball
anymore.
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
gcc 7 with -Os (optimize for size) takes the liberty to remove the code
of inline functions entirely - which is indeed allowed according to the
C99 standard, cfr. this [1] very complete StackOverflow answer. This
leads to undefined function references at link time.
The proper approach is to patch the code to use 'static inline'
instead. However, for various reasons such a patch is not entirely
trivial, and upstream has not moved since 7 years, so instead take the
simpler approach of restoring the gcc original inline behaviour with
-fgnu89-inline to fix this issue.
Fixes http://autobuild.buildroot.org/results/d72/d72a7e9775a10bc884b9953dd2eba3ad32100cca
[1] https://stackoverflow.com/questions/6312597/is-inline-without-static-or-extern-ever-useful-in-c99
Signed-off-by: Francois Perrad <francois.perrad@gadz.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This partially reverts commit cf6d321e9d.
The underlying reason for doing the checks is to ensure that a
merged-usr setting is properly enforced, even for custom skeletons.
Before that patch, a custom skeleton where both /bin and /usr/bin were
missing was accepted; but then the first package that intalled something
in /bin would create it as a directory, thus breaking the merged-usr
situation. Ditto sbin and lib, of course.
cf6d321 was created to detect that situation, and the fix was to require
that both directories do exist in the custom skeleton, so that we new
the check for consistency were OK, in all cases.
However, that broke existing skeletons which where missing both
directories, and some people are shinning about it...
The crux of the problem is that Buildroot should be responsible for
creating the directories or the symliks when they are missing, and only
fail if the existing ones are incorrect, but not impose the burden on
the user.
A situation where the problem arises is when a skeleton is shared
between various builds, some using a merged-usr while other do not.
We fix that by reverting the offending changes change, back to the
previous behaviour. We keep the stderr redirection in stat calls, and
the variable renaming.
A proper fix to create the missing directories can be added later.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Cc: Arnout Vandecappelle <arnout@mind.be>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
gdb 7.12+ is compiled and linked with C++, therefore the thread_db
headers need to use extern "C", to be usable for C++ code.
Fixes:
Issue when building gdbserver for m68k-coldfire:
thread-db.o: In function `thread_db_init()':
thread-db.c:(.text+0x5b6): undefined reference to `td_ta_new(ps_prochandle*, td_thragent**)'
thread-db.c:(.text+0x61e): undefined reference to `td_thr_get_info(td_thrhandle const*, td_thrinfo*)'
thread-db.c:(.text+0x632): undefined reference to `td_symbol_list()'
...
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This change is fixing the bug reported in [1].
Cmake may run pkg-config to find the dependencies when configuring a
package. Because of the value of PATH, and it will use the Buildroot's
pkg-config wrapper, which, by default, is configured (via some
environment variables) to find the target dependencies.
When configuring a host package using cmake, to prevent cmake from
wrongly solving dependencies from the target tree (when the
*-config.cmake files are using pkg-config) instead of looking for them
in the Buildroot's host tree or in the host system itself, we need to
set the environment variables altering the pkg-config behavior in the
cmake configure environment.
So, this change is fixing the cmake host-packages configuration step,
by properly setting the pkg-config environment variables to their values
for finding host dependencies.
Before this patch:
make O=/opt/br/abo/cmake-host-find-root-path libxml2 host-mariadb{-dirclean,-configure} && echo $?
[...]
>>> host-mariadb 10.1.25 Configuring
(mkdir -p /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ && cd /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ && rm -f CMakeCache.txt && PATH="/opt/br/abo/cmake-host-find-root-path/host/bin:/opt/br/abo/cmake-host-find-root-path/host/sbin:/home/sam/.local/bin:/sbin:/usr/sbin:/bin:/usr/bin" /usr/bin/cmake /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_FIND_ROOT_PATH="/opt/br/abo/cmake-host-find-root-path/host" -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH" -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY="BOTH" -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE="BOTH" -DCMAKE_INSTALL_PREFIX="/opt/br/abo/cmake-host-find-root-path/host" -DCMAKE_C_FLAGS="-O2 -I/opt/br/abo/cmake-host-find-root-path/host/include" -DCMAKE_CXX_FLAGS="-O2 -I/opt/br/abo/cmake-host-find-root-path/host/include" -DCMAKE_EXE_LINKER_FLAGS="-L/opt/br/abo/cmake-host-find-root-path/host/lib -Wl,-rpath,/opt/br/abo/cmake-host-find-root-path/host/lib"
-DCMAKE_ASM_COMPILER="/usr/bin/as" -DCMAKE_C_COMPILER="/usr/bin/gcc" -DCMAKE_CXX_COMPILER="/usr/bin/g++" -DCMAKE_C_COMPILER_ARG1="" -DCMAKE_CXX_COMPILER_ARG1="" -DCMAKE_COLOR_MAKEFILE=OFF -DBUILD_DOC=OFF -DBUILD_DOCS=OFF -DBUILD_EXAMPLE=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TEST=OFF -DBUILD_TESTS=OFF -DBUILD_TESTING=OFF -DWITH_SSL=bundled )
-- Running cmake version 3.8.2
[...]
-- Found PkgConfig: /opt/br/abo/cmake-host-find-root-path/host/bin/pkg-config (found version "0.28")
[...]
-- Found LibXml2: /opt/br/abo/cmake-host-find-root-path/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/libxml2.so (found version "2.9.4")
[...]
0
After this patch is applied:
make O=/opt/br/abo/cmake-host-find-root-path libxml2 host-mariadb{-dirclean,-configure} && echo $?
[...]
>>> host-mariadb 10.1.25 Configuring
(mkdir -p /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ && cd /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ && rm -f CMakeCache.txt && PATH="/opt/br/abo/cmake-host-find-root-path/host/bin:/opt/br/abo/cmake-host-find-root-path/host/sbin:/home/sam/.local/bin:/sbin:/usr/sbin:/bin:/usr/bin" PKG_CONFIG="/opt/br/abo/cmake-host-find-root-path/host/bin/pkg-config" PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_LIBDIR="/opt/br/abo/cmake-host-find-root-path/host/lib/pkgconfig:/opt/br/abo/cmake-host-find-root-path/host/share/pkgconfig" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1 PKG_CONFIG_ALLOW_SYSTEM_LIBS=1 /usr/bin/cmake /opt/br/abo/cmake-host-find-root-path/build/host-mariadb-10.1.25/ -DCMAKE_INSTALL_SO_NO_EXE=0 -DCMAKE_FIND_ROOT_PATH="/opt/br/abo/cmake-host-find-root-path/host" -DCMAKE_FIND_ROOT_PATH_MODE_PROGRAM="BOTH" -DCMAKE_FIND_ROOT_PATH_MODE_LIBRARY="BOTH" -DCMAKE_FIND_ROOT_PATH_MODE_INCLUDE="BOTH" -DCMAKE_INSTALL_PREFIX="/opt/br/abo/cmake-host-find-roo
t-path/host" -DCMAKE_C_FLAGS="-O2 -I/opt/br/abo/cmake-host-find-root-path/host/include" -DCMAKE_CXX_FLAGS="-O2 -I/opt/br/abo/cmake-host-find-root-path/host/include" -DCMAKE_EXE_LINKER_FLAGS="-L/opt/br/abo/cmake-host-find-root-path/host/lib -Wl,-rpath,/opt/br/abo/cmake-host-find-root-path/host/lib" -DCMAKE_ASM_COMPILER="/usr/bin/as" -DCMAKE_C_COMPILER="/usr/bin/gcc" -DCMAKE_CXX_COMPILER="/usr/bin/g++" -DCMAKE_C_COMPILER_ARG1="" -DCMAKE_CXX_COMPILER_ARG1="" -DCMAKE_COLOR_MAKEFILE=OFF -DBUILD_DOC=OFF -DBUILD_DOCS=OFF -DBUILD_EXAMPLE=OFF -DBUILD_EXAMPLES=OFF -DBUILD_TEST=OFF -DBUILD_TESTS=OFF -DBUILD_TESTING=OFF -DWITH_SSL=bundled )
-- Running cmake version 3.8.2
[...]
-- Found PkgConfig: /opt/br/abo/cmake-host-find-root-path/host/bin/pkg-config (found version "0.28")
[...]
-- Found LibXml2: /usr/lib/libxml2.so (found version "2.9.4")
[...]
0
[1] http://lists.busybox.net/pipermail/buildroot/2017-August/199776.html
Reported-by: "Sigalas, Antonios (Nokia - GR/Athens)" <antonios.sigalas@nokia.com>
Cc: "Sigalas, Antonios (Nokia - GR/Athens)" <antonios.sigalas@nokia.com>
Cc: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Commit 0e2ee0e6e8 (package.snappy: fix static builds with threads)
added LIBS=-pthread to configure options to fix static build with
threads on some architectures. This works for autotools packages. Then,
commit d26282b3aa (package/snappy: bump version, switch to cmake)
switched to cmake that does not understand the 'LIBS' parameter.
As pointed out by Thomas[1] the special handling of libpthread for
static builds is not needed anymore: it was needed only to build the
tests, and these are no longer built. Note that packages that link
statically with snappy will still need to link with -pthread. Only
two in-tree packages currently depend on snappy: lua-csnappy depends
on !BR2_STATIC_LIBS and leveldb adds -pthread from its build system.
Tested with the following musl & uclibc defconfigs which also fix build
errors:
http://autobuild.buildroot.net/results/39f/39f9fc4300ddca19e8a533765b46838003752000/http://autobuild.buildroot.net/results/886/8860b9259f7a3aecb2ddbfa787be048072bd347b/
[1] http://lists.busybox.net/pipermail/buildroot/2017-July/199549.html
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[Baruch: improved commit message]
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
[Arnout: improved commit message more, based on Yann's input]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This fixes the following build issues:
In file included from ../sysdeps/x86_64/multiarch/varshift.c:19:0,
from ../sysdeps/i386/i686/multiarch/varshift.c:1:
../sysdeps/x86_64/multiarch/varshift.h: In function '__m128i_shift_right':
../sysdeps/x86_64/multiarch/varshift.h:26:1: error: SSE vector return without SSE enabled changes the ABI [-Werror=psabi]
{
[...]
.../lib/gcc/i686-buildroot-linux-gnu/7.1.0/include/tmmintrin.h:136:1: error: inlining failed in call to always_inline '_mm_shuffle_epi8': target specific option mismatch
The patch has been taken from glibc's patchwork at
https://patchwork.sourceware.org/patch/21003/.
Fixes bug #10156.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Versions older than Linux v3.7 do not support the aarch64 architecture
so disable them, for reference see https://kernelnewbies.org/Linux_3.7
Without this patch these defconfigs fail to build
BR2_aarch64=y
BR2_KERNEL_HEADERS_3_2=y
BR2_aarch64=y
BR2_KERNEL_HEADERS_3_4=y
with error messages like this:
make[1]: Entering directory '/home/buildroot/br5_next/output/build/linux-headers-3.2.89'
Makefile:567: /home/buildroot/br5_next/output/build/linux-headers-3.2.89/arch/arm64/Makefile: No such file or directory
Signed-off-by: Bernd Kuhls <bernd.kuhls@t-online.de>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
With binutils 2.29 a runtime error is seen:
Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100
Backport upstream patch to fix the issue.
Signed-off-by: Waldemar Brodkorb <wbx@openadk.org>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
BR2_PACKAGE_SKELETON_NONE does not provide the /var subdirectory which
breaks symlink creation in that directory. Make sure that /var exists
before creating the symlink.
Fixes:
http://autobuild.buildroot.net/results/32d/32dff0df759baf1120e4f11335e735eb0708b237/
Signed-off-by: Baruch Siach <baruch@tkos.co.il>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fixes [1]:
make[1]: Entering directory '.../build/qt5base-5.9.1/examples/opengl'
cd hellowindow/ && ( test -e Makefile || .../build/qt5base-5.9.1/bin/qmake -o Makefile .../build/qt5base-5.9.1/examples/opengl/hellowindow/hellowindow.pro ) && make -f Makefile
make[2]: Entering directory '.../build/qt5base-5.9.1/examples/opengl/hellowindow'
.../host/bin/sparc-linux-g++ -c -pipe -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -Os --sysroot=.../host/sparc-buildroot-linux-uclibc/sysroot -O2 -O3 -fno-exceptions -Wall -W -D_REENTRANT -fPIC -DQT_NO_EXCEPTIONS -D_LARGEFILE64_SOURCE -D_LARGEFILE_SOURCE -DQT_NO_DEBUG -DQT_GUI_LIB -DQT_CORE_LIB -I. -I../../../include/QtGui/5.9.1 -I../../../include/QtGui/5.9.1/QtGui -I../../../include -I../../../include/QtGui -I../../../include/QtCore/5.9.1 -I../../../include/QtCore/5.9.1/QtCore -I../../../include/QtCore -I.moc -I../../../mkspecs/devices/linux-buildroot-g++ -o .obj/hellowindow.o hellowindow.cpp
In file included from hellowindow.cpp:51:0:
hellowindow.h:96:5: error: ‘QOpenGLShaderProgram’ does not name a type
QOpenGLShaderProgram *m_program;
^~~~~~~~~~~~~~~~~~~~
hellowindow.h:97:5: error: ‘QOpenGLBuffer’ does not name a type
QOpenGLBuffer m_vbo;
^~~~~~~~~~~~~
hellowindow.cpp: In constructor ‘Renderer::Renderer(const QSurfaceFormat&, Renderer*, QScreen*)’:
hellowindow.cpp:62:40: error: invalid use of incomplete type ‘class QOpenGLContext’
m_context = new QOpenGLContext(this);
^
In file included from ../../../include/QtGui/qsurfaceformat.h:1:0,
from ../../../include/QtGui/../../src/gui/kernel/qsurface.h:45,
from ../../../include/QtGui/qsurface.h:1,
from ../../../include/QtGui/../../src/gui/kernel/qwindow.h:51,
from ../../../include/QtGui/qwindow.h:1,
from ../../../include/QtGui/QWindow:1,
from hellowindow.h:51,
from hellowindow.cpp:51:
[1] http://autobuild.buildroot.net/results/001/001bc930014fca8c2a8b7a390350b4e1a15fa375/build-end.log
Signed-off-by: Peter Seiderer <ps.report@gmx.net>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This version is compatible with LibreSSL.
Signed-off-by: Adam Duskett <Adamduskett@outlook.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Fixes the following build failure, which occurs on all architectures:
/tmp/cc6APNmN.s: Assembler messages:
/tmp/cc6APNmN.s: Error: `loc1@GLIBC_2.17' can't be versioned to common symbol 'loc1'
/tmp/cc6APNmN.s: Error: `loc2@GLIBC_2.17' can't be versioned to common symbol 'loc2'
/tmp/cc6APNmN.s: Error: `locs@GLIBC_2.17' can't be versioned to common symbol 'locs'
../o-iterator.mk:9: recipe for target '/tmp/output/build/glibc-2.25/build/misc/regexp.os' failed
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Microblaze support was never upstreamed in gdb. We currently use a gdb
from the Xilinx Github repository, but this gdb is based on 7.6, and
has never been updated in the last 4 years. There are no other active
branches at https://github.com/Xilinx/gdb/branches.
Xilinx has a slightly newer gdb, based on 7.7, available at
https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb. However,
it's apparently only available in the form of stack of big patches
(https://github.com/Xilinx/meta-xilinx/tree/master/recipes-microblaze/gdb/files).
Currently, gdb on Microblaze fails to build in various conditions:
* Against glibc, with "error: conflicting types for 'ps_lgetfpregs'"
* Against musl, with "error: unknown type name 'elf_gregset_t'"
While those issues can probably be fixed, the fact that there is no
active upstream significantly reduces the incentive to fix those
problems.
Therefore, let's drop support for gdb on Microblaze entirely.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Romain Naour <romain.naour@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
After c0ad6ded01 expat: security bump to version 2.2.1
the system can hang on startup under certain circumstances.
This happens when:
* we use systemd as init system
* the random nonblocking pool takes a while to initialize
* this apparently doesn't happen on qemu, so this would not have
been caught by the runtime testing infrastructure
* it also doesn't seem to happen when network booting
For a more detailed description of the bug see here:
https://bugs.freedesktop.org/show_bug.cgi?id=101858
The patch should be in next dbus version 1.10.24
Set DBUS_AUTORECONF = YES because configure.ac is changed.
Signed-off-by: Marcus Hoffmann <m.hoffmann@cartelsol.com>
[Arnout: add upstream commit sha + Marcus's Sob to the patch]
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
This fixes a recursive variable definition introduced by the refactoring
in commit 120307520f. Simply rename the
hook to remove the recursion.
Fixes https://bugs.busybox.net/show_bug.cgi?id=10146
Signed-off-by: Stefan Becker <chemobejk@gmail.com>
The azmq library provides Boost Asio style bindings for ZeroMQ. This
library is built on top of ZeroMQ's standard C interface and is intended
to work well with C++ applications which use the Boost libraries in
general, and Asio in particular.
Signed-off-by: RJ Ascani <rj.ascani@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Using the package instrumentation hooks, a file packages-file-list.txt is
created containing the list of files installed by a package with their size.
Due to the use of 'find -type f', symbolic links to files are not included
in this file list. Since the original purpose of this file was to calculate
the total size of a package and symbolic links have file size 0, this was
not a problem.
However, if packages-file-list.txt is reused for other purposes, for example
to get a complete list of files installed by a package regardless of size,
symbolic links to files are important too.
Likewise, to get a complete view of what a package installs, directories
should be included too.
Update the instrumentation hook accordingly.
Although for files an md5sum is taken, we cannot do this for directories.
Instead, mimic the output of md5sum with a fake hash string.
Note: for directories that are used by several packages, e.g. /etc/init.d/,
the package that created the directory will be treated as the 'owner' of
that directory. This gives a somewhat distorted view of ownership.
Similarly, the package size reported by 'make graph-size' (based on
packages-file-list.txt) will include the 'size' of a directory for that
owner, which is reported as e.g. 4096 bytes.
Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
