The $(BUILD_DIR)/.root rule is executed as part of the 'dirs'
target. The 'dirs' target is re-executed at every execution of 'make
external-deps', and make external-deps explicitly tells make to ignore
targets that have already been made (through the -B option). This
means that the $(BUILD_DIR)/.root rule has to be idempotant, which was
not the case this the introduction of the lib32/lib64 symbolic link.
Running 'make external-deps' three times in a row was sufficient to
trigger an error due to symbolic links being incorrectly created. This
patch fixes that.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The strongswan configure.in uses the AC_LIB_PREFIX macro, which adds
--with-lib-prefix and --without-lib-prefix options, and which, by
default assumes that adding ${prefix}/lib to LDFLAGS and
${prefix}/include to CPPFLAGS is a good idea. Obviously, when
cross-compiling, it is definitely not a good idea.
In the specific case of strongswan, the result is that when testing if
the backtrace() function was available, the small C program was being
built and linked with -L/usr/lib. So when the host architecture and
target architecture are identical, it may find the backtrace()
function in the host C library, without looking at the target C
library:
configure:16457: /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/usr/bin/x86_64-unknown-linux-uclibc-gcc -o conftest -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -pipe -Os -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -L/usr/lib conftest.c >&5
/home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/bin/ld: warning: libc.so.0, needed by /home/test/outputs/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/output/host/opt/ext-toolchain/bin/../lib/gcc/x86_64-unknown-linux-uclibc/4.6.3/../../../../x86_64-unknown-linux-uclibc/lib/../lib64/libgcc_s.so, may conflict with libc.so.6
Passing --without-lib-prefix prevents this default behavior from
happening, and no stupid value is added to CPPFLAGS or LDFLAGS.
Fixes:
http://autobuild.buildroot.net/results/a637f916962b6136dd6dd4f4b9ff4e1cab568ef3/
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The MesaLib 7.10.3 tarball has been moved on ftp.freedesktop.org from
pub/mesa/7.10.3/ to pub/mesa/old_versions/7.x/7.10.3/.
A bump to a newer release is only coming after Buildroot 2013.08, so for now
let us just change URL to let the download work properly.
Reported-by: Ryan Wilkins <ryan@deadfrog.net>
Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Some parts of redis fail to build when ccache is enabled, due to one of our
own patches. The construct
make CC=$(CC) target1 target2
would result in
make CC=ccache <tuple>-gcc target1 target2
and here <tuple>-gcc would be treated as a target and the compiler used
would be just 'ccache'.
Reported-by: Johan Sagaert <sagaert.johan@skynet.be>
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Since 5628776c4a
"toolchain-external: fix lib64 symlinks"
lib64 is a symlink to lib so there is no reason to copy the libraries
to lib64 anymore. This fixes multiple building problems
for buildroot toolchains:
[...]
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libuClibc-0.9.33.2.so'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libuClibc-0.9.33.2.so'
are the same file
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libutil-0.9.33.2.so'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libutil-0.9.33.2.so'
are the same file
mv: 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64/libutil.so.0'
and 'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib/libutil.so.0'
are the same file
rmdir: failed to remove
'output/host/usr/mips64-buildroot-linux-uclibc/sysroot/lib64': Not a directory
[...]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Reviewed-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
minidlna will detect and use the libiconv library if
the package is selected. In that case, we need to link
against -liconv.
Fixes the following linking problem:
tagutils/tagutils.o: In function `do_iconv.constprop.6':
tagutils.c:(.text+0x4d5c): undefined reference to `libiconv_open'
tagutils.c:(.text+0x4da0): undefined reference to `libiconv'
tagutils.c:(.text+0x4e08): undefined reference to `libiconv_close'
[Peter: wrap COMMON_LIBS line]
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
* Always link lib64 or lib32 to lib
* Only copy the architecture's lib directory to staging
* Also cleanup a couple of mkdirs (concerning some 'lib' directories).
Before this patch:
$ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib*
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:26 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/
drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/
drwxr-xr-x 5 samuel users 4.0K Aug 12 22:27 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/
drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/lib64 -> lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:27 target/usr/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:27 target/usr/lib64 -> lib/
$ find . -type l -xtype l # find broken symlinks
find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64/lib': Too many levels of symbolic links
find: `./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64/lib': Too many levels of symbolic links
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_files.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nis.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_compat.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_nisplus.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libutil.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libthread_db.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcidn.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libcrypt.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libm.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_hesiod.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnsl.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/librt.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_db.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libanl.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libBrokenLocale.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libnss_dns.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libresolv.so
./host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/libdl.so
./target/etc/resolv.conf
./target/dev/log
After this patch:
$ ls -ld host/usr/x86_64-buildroot-linux-gnu/sysroot/{,usr/}lib* target/{usr/,}lib*
drwxr-xr-x 2 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib/
lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/lib64 -> lib/
drwxr-xr-x 5 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib/
lrwxrwxrwx 1 samuel users 5 Aug 12 22:36 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/lib64 -> lib/
drwxr-xr-x 3 samuel users 4.0K Oct 30 2012 host/usr/x86_64-buildroot-linux-gnu/sysroot/usr/libexec/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/lib64 -> lib/
drwxr-xr-x 2 samuel users 4.0K Aug 12 22:36 target/usr/lib/
lrwxrwxrwx 1 samuel users 3 Aug 12 22:36 target/usr/lib64 -> lib/
$ find . -type l -xtype l # find broken symlinks
./target/etc/resolv.conf
./target/dev/log
Fixes http://autobuild.buildroot.net/results/23fb6b1479d2b5906b72c9437b06ab4700ff246d/
Signed-off-by: Samuel Martin <s.martin49@gmail.com>
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The NEON intrinsics used by Pulseaudio are only available in either
-mfloat-abi=softfp or -mfloat-abi=hard, not in
-mfloat-abi=soft. Therefore having NEON support in the processor is
not sufficient, we also should *not* be using soft-float.
Moreover, looking at BR2_ARM_ENABLE_NEON to know if the processor has
NEON support is incorrect. This option is only here to allow the user
to tell whether the processor has NEON support or not, for the ARM
cores that only have optional NEON support. Instead, the
BR2_ARM_CPU_HAS_NEON option really indicates whether NEON is available
or not (it is either set automatically by the ARM cores that always
have NEON support, or when BR2_ARM_ENABLE_NEON is enabled by the user
to confirm that his ARM processor has NEON support).
This fixes build failures such as
http://autobuild.buildroot.org/results/675/675c96059be348b594cc92980bef391126931c83/build-end.log
[Peter: add comment about reason for soft abi check]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The current code to set ABI on ARM does the following:
ifeq ($(BR2_arm)$(BR2_armeb),y)
... set ABI without 'hf' suffix ...
else ifeq ($(BR2_ARM_EABIHF),y)
... set ABI with 'hf' suffix ...
endif
But since $(BR2_arm)$(BR2_armeb) will always be 'y' in the cases where
BR2_ARM_EABIHF is 'y', it means that the 'else' part of the condition
will never be used.
Fix this by appending 'hf' to the ABI variable when BR2_ARM_EABIHF is
selected.
[Peter: put EABIhf handling under arm/armeb conditional for consistency]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Several of the lines in S50sshd script have a strange mix of spaces
and tabs, that at least do not look consistent with neighboring lines.
This patch makes the spacing consistent, and also strips the trailing
spaces.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The $(TARGET_DIR) variable is required when building
python-setuptools for the target otherwise the build system detects
the host installation which leads to permission error problems
like these:
Setuptools installation detected at /usr/lib64/python2.7/site-packages
Renaming /usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info to
/usr/lib64/python2.7/site-packages/setuptools-0.9.8-py2.7.egg-info.OLD.1377005697.88
OSError: [Errno 13] Permission denied
Moreover, remove the PYTHONPATH variable for host variant since it's
not needed.
Signed-off-by: Markos Chandras <markos.chandras@imgtec.com>
Tested-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
If the file to be patched is missing, then `patch' will interactively
ask for a file to be patched. This is annoying in e.g. the autobuilders
because they have to wait for a timeout instead of failing.
Giving the '-t' (batch mode) option to patch fixes this: it will skip the
missing file, and return a non-zero exit code. So the build cleanly
fails.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Commit fde2605765 (Makefile: test before search for kernel modules)
changed the way we strip kernel modules, but it fails when modules aren't
available (as test -d returns with a non zero exit code).
Fix it by including the test -d call in a proper shell conditional.
Reported-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The 'find $(TARGET_DIR)/lib/modules' used to find and strip kernel
modules fails when no kernel modules have been installed. While the
'|| true' prevents the entire build from failing, there are still some
error messages displayed, which is not nice.
Instead, test if the directory exists before doing the find. We also
remove the '|| true' in order to really abort the build if a
problematic error occurs.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Luca Ceresoli <luca@lucaceresoli.net>
Just like 'attr', 'acl' doesn't use automake to control the
build/installation of its components, and the static-only installation
process was not installing libacl.a. We add a patch that fixes this.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
When attr is built static-only, it forgets to install its libattr.a
file, which leads to the build failure of packages such as 'acl' that
rely on attr.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
'cut' needs to be invoked with the -s option to make sure it doesn't
print anything when the delimiter isn't found. This is particularly
important for the charmap detection, because UTF-8 is appended if
the charmap is empty. But without -s, it will never be empty.
Signed-off-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The Qt5 upstream URL has changed, which leads to build failures in the
autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
