The LEDE buildbots currently fail to build the package since there seems
to be a problem with the emacs installed on the buildbot(s) (e.g. [1]):
-snip-
Making all in emacs
make[7]: Entering directory `/opt/buildbot/slaves/lede-slave-tah/x86_64/build/sdk/build_dir/target-x86_64_musl-1.1.15/autoconf-2.69/lib/emacs'
WARNING: Warnings can be ignored. :-)
if test "emacs" != no; then \
set x; \
list='autoconf-mode.el autotest-mode.el'; for p in $list; do \
if test -f "$p"; then d=; else d="./"; fi; \
set x "$@" "$d$p"; shift; \
done; \
shift; \
EMACS="emacs" /bin/bash ../../build-aux/elisp-comp "$@" || exit 1; \
else : ; fi
4;1H; last errno 10)
No buffers needed saving: you didn't lose any work.
mv: cannot stat '*.elc': No such file or directory
make[7]: *** [elc-stamp] Error 1
-snap-
So let's disable the emacs usage - the resulting artifacts are not
packaged at the moment at all.
[1] https://downloads.lede-project.org/snapshots/faillogs/x86_64/packages/autoconf/compile.txt
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Acked-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
We're currently preparing a change in LEDE that will change the host
staging dirs in a way that might break the sed commands used by the
automake Makefile. Change the command in a way that doesn't depend on the
path of the staging dir.
While it would be nicer to modify the configure script to use the correct
path in the first place, this doesn't work for the perl path, as perl is
used in shebang lines and must thus be an absolute path. Some scripts are
used both during build and on the target system, so fixing up the scripts
in the install step seems like the best option.
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
We can just set M4 in the configure command instead of fixing up the paths
using sed afterwards. This makes the build more robust (and we're currently
preparing a change of the host staging dirs in LEDE that might break this
otherwise).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
We can just set GREP and SED in the configure command instead of fixing up
the paths using sed afterwards. This makes the build more robust (and we're
currently preparing a change of the host staging dirs in LEDE that might
break this otherwise).
Signed-off-by: Matthias Schiffer <mschiffer@universe-factory.net>
Add two patches to address three distinct build problems spotted by our
build bots when compiling lttng-tools:
1) unconditional use of `__GLIBC_PREREQ`
On musl based toolchains there is no such macro defined, leading to the
following preprocessor error:
CC compat-epoll.lo
In file included from compat-epoll.c:33:0:
poll.h:76:19: error: missing binary operator before token "("
#if __GLIBC_PREREQ(2, 9)
2) undeclared `mode_t` type
On musl based toolchains the `mode_t` type is not implicitely defined through
other includes, leading to the following compile error:
CC hashtable.lo
In file included from ../../../src/common/common.h:24:0,
from hashtable.c:24:
../../../src/common/runas.h:25:46: error: unknown type name 'mode_t'
int run_as_mkdir_recursive(const char *path, mode_t mode, uid_t uid, gid_t gid);
^
../../../src/common/runas.h:26:36: error: unknown type name 'mode_t'
int run_as_mkdir(const char *path, mode_t mode, uid_t uid, gid_t gid);
^
../../../src/common/runas.h:27:46: error: unknown type name 'mode_t'
int run_as_open(const char *path, int flags, mode_t mode, uid_t uid, gid_t gid);
^
3) multiple definitions
The header files declare several `const char *` pointers which are initialized
in various `*.c` files later on. Due to a missing `extern` declaration in the
header, the final linking of the executables fails with errors such as:
CCLD lttng
../../../src/common/.libs/libcommon.a(mi-lttng.o):(.data.rel.ro.local+0x0): multiple definition of `mi_lttng_element_snapshots'
commands/enable_events.o:(.bss+0x18): first defined here
collect2: error: ld returned 1 exit status
This commits addresses these issues with two patches, `100-musl-compat.patch`
fixes issue 1 by declaring a fallback dummy declaration of `__GLIBC_PREREQ` and
issue 2 by explicitely including `sys/stat.h` which provides `mode_t` according
to POSIX.
The second patch, `200-use-extern.patch` declares all char pointers in the
header file as `extern`, fixing the observed linker errors.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
GNU libtool is used to ease the usage of shared libraries in Makefiles.
The new package libtool-bin contains the script libtoolize which is used
to prepare a package to use libtool.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
To make automake work correctly it is necessary to have files
* automake
* aclocal
* automake-$(PKG_VERSION)
* aclocal-$(PKG_VERSION)
The files without version number can be supplied as symbolic
links.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
pkg-config is a helper tool used when compiling applications and libraries.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[Fixed trailing whitespace in package description.]
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
Automake is a tool for automatically generating Makefile.in files compliant
with the GNU Coding Standards.
A new package automake is provided.
version 2:
do not reference staging directory in distributed files
copy only one version of automake
resolve whitespace issues
CC: Michael Heimpold <mhei@heimpold.de>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
This patch provides package autoconf.
Autoconf is required to generated the configure script of autotools
projects.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[Fixed commit summary (first line of commit message)]
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
GNU M4 is a prerequisite to run autoconf and automake.
This patch packages the macro processor.
This is a prerequisite for packaging autoconf and automake.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
[Fixed commit summary according to our best-practise]
Signed-off-by: Michael Heimpold <mhei@heimpold.de>
OpenWRT provides gcc but lacks make. So building foreign software is
difficult.
This patch provides GNU Make 4.1.
Built on Debian Jessie amd64.
Tested on TP-Link MR3020 (ar71xx/generic).
version 4:
remove gnumake.h from the package
We could package it in a separate make-dev package if really needed.
version 3:
use Build/InstallDev to provide build time dependency
version 2:
superfluous lines removed as suggested by Yousong Zhou
CC: Yousong Zhou <yszhou4tech@gmail.com>
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
Compile with `-std=gnu99` instead of `-std=c99` to avoid redefining
`__attribute__` in `src/system.h`.
Fixes the following error spotted by the buildbot:
In file included from ../lib/stdio.h:43:0,
from cmp.c:22:
.../staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-linaro_musl-1.1.10_eabi/include/fortify/stdio.h: In function 'snprintf':
.../staging_dir/toolchain-arm_cortex-a9+vfpv3_gcc-4.8-linaro_musl-1.1.10_eabi/include/fortify/stdio.h:99:2: error: invalid use of '__builtin_va_arg_pack ()'
return __orig_snprintf(__s, __n, __f, __builtin_va_arg_pack());
^
Signed-off-by: Jo-Philipp Wich <jow@openwrt.org>
Bump GNU patch from 2.7.4 to 2.7.5.
Changelog: http://git.savannah.gnu.org/cgit/patch.git/tree/NEWS
Changes in version 2.7.5:
* There are users which expect patch to follow symbolic links in the working
directory, so patch now again follows symbolic links as long as they do not
leave the working directory.
Signed-off-by: Hannu Nyman <hannu.nyman@iki.fi>
Right now these are arm, hppa, microblaze, powerpc, sh and xtensa.
So we just try to grep for it to figure out if it is needed.
Signed-off-by: Harald Geyer <harald@ccbib.org>
Signed-off-by: Christian Beier <dontmind@freeshell.org>
The build system somehow detects /usr/include/sys/sdt.h, which is part of systemtap-sdt-devel
package in the host environment but not present in the SDK.
This patch simply disables the check for sys/sdt.h, enabling building of this package when
systemtap-sdt-devel is installed in the host environment.
Signed-off-by: Christian Beier <dontmind@freeshell.org>