Prepare for the merge of audio and video packages. Many packages cannot
properly be assigned to either audio or video, because they have support
for both (libogg, mplayer, vlc).
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
Also remove --enable-shared and --enable-static as it's default
and --disable-oggtest and $(DISABLE_NLS) as they are not supported.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
This patch adds a patch to fix bug
https://bugs.freedesktop.org/show_bug.cgi?id=16464 affecting parallel
compilation of fontconfig.
The patch is the one proposed in the bugzilla entry, available at
https://bugs.freedesktop.org/attachment.cgi?id=17294.
Without this patch, the compilation (at BR2_JLEVEL > 1) of fontconfig
sometimes fails with:
In file included from fc-case.c:25:
../src/fcint.h:118:21: error: fcalias.h: No such file or directory
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch fixes two Qtopia build issues, encountered while trying to
use system implementation of zlib, freetype, jpeg and libpng :
* The build process doesn't look in $(STAGING_DIR)/usr/include for
includes and $(STAGING_DIR)/usr/lib. Same problem as the patch
currently floating around adding LDFLAGS to TARGET_CONFIGURE_OPTS,
but as Qtopia doesn't use TARGET_CONFIGURE_OPTS, we need a specific
fix here. So we use the -I and -L options of Qtopia's configure
script.
* The build process doesn't use pkg-config to get the header path for
Freetype headers (located in $(STAGING_DIR)/usr/include/freetype2
and not directly in $(STAGING_DIR)/usr/include/). There was already
a fix for this, consisting in adding $(FREETYPE_DIR)/include to the
-I path of Qtopia's configure. This patch modifies this fix to use
$(STAGING_DIR)/usr/include/freetype2 instead, which looks more
coherent with how all the packages are built (using $(STAGING_DIR)
as the reference to get headers and libraries).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
This patch is a new version of a patch already sent several times on
the mailing-list, committed and reverted a few times by Daniel Laird,
due to several imperfections. This version is a new try at finding a
solution that works for everybody. Hopefully it'll work :-)
The original problem is that external toolchain builds failed because
packages couldn't find their dependent libraries at configure time and
could not be linked with them. To fix these two problems, two things
are added:
* The TARGET_LDFLAGS variable was exposed as LDFLAGS at ./configure
time thanks to TARGET_CONFIGURE_OPTS. The TARGET_LDFLAGS variable
contains -L options with the path in the STAGING_DIR for the
libraries. It allows ./configure scripts to properly compile the
small test programs testing whether a dependency is properly
installed.
* The TARGET_CFLAGS contains a new -Wl,--rpath-link option for both
$(STAGING_DIR)/lib and $(STAGING_DIR)/usr/lib. It allows library
depending on other libraries to link properly. The TARGET_CFLAGS is
exposed as CFLAGS in TARGET_CONFIGURE_OPTS.
This new version fixes a problem encountered by hartleys
<hartleys@visionengravers.com> when building the kernel. The problem
was that the -Wl,--rpath-link options were added to LDFLAGS, while
there are options for the C compiler, not the ld linker. Moving them
to CFLAGS seems to fix the issue.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Bounce tiff into Autotools.in format.
Did not use install to target as this puts loads of executables into TARGET.
So just copied tiff.so instead.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Looking into adding a configure cache to the build (like the GIT buildroot version)
This means that freetype needs to know about zlib so make
sure it had it as a dependency.
Also remove install rule for staging as it matches default.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
The following patch makes the MESSAGE Macro in Makefile.autotools.in
work.
I think it was originally intended to print the messages in bold type
but it doesn't appear to work correctly. This patch should work on all
platforms.
Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com>
(Fixed to not continously call tput)
Revert the rpath patch, it looked good up until someone tried
to build a kernel as well. This seems to break as a result.
Will post a new patch soon and see how that goes..
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Apply the patch I posted some time ago that fixes
rpath issues with external toolchains.
Has been tested by users of buildroot and feedback looks good.
Signed-off-by: Thomas Petazzoni
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
This patch will make the installation of modules rule depend on .depend_done instead of .configured to make sure make prepare is run before modules are installed.
Make kernelversion does not work before make prepare has been run.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch will add a rule to top level Makefile to depend on the
$(PROJECT_BUILD_DIR)/autotools-stamps as a required directory. Hence it will be
generated if missing in stead of made when the $(PROJECT_BUILD_DIR)/.root rule
is triggered.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch will create the autotools-stamps directory early in the build
process, thus making it possible for non Makefile.autotools.in packages to use
this directory to hold stamp files.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch adds gettext dependency to make: rule instead of the TARGETS
variable if locale is selected. Just to conform with common syntax.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch makes sure gettext and libintl are selected if locale support is
enabled. Gettext must also be compiled before make so appropriate headers are
available to make.
Signed-off-by: Hans-Christian Egtvedt <hans-christian.egtvedt@atmel.com>
This patch prevents the user from select "linux (Same version as linux
headers)" as a choice for building the kernel when an external binary
toolchain is used, since "same version as linux headers" doesn't make
sense when an external toolchain is used.
It fixes the issue encountered by Hartley <hartleys@visionengravers.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
HOST_GLIB is set to the path that contains the host glib tool set and is
used when building packages using glib. The buildroot top level Makefile
sets HOST_GLIB using which to find the path where glib-genmarshal is
located.
The problem is that a cross compiled version of glib-genmarshal is also
put in the build_ARCH/staging_dir/usr/bin directory when the package
libglib2 is built. This cross compiled version will typically not run on
the host system.
Fix it by ignoring staging_dir in the which output.
Closes#5934
jacmet: fixed to work correctly if it's only found in staging_dir.
External toolchain C++ cross-compiler fix
package/Makefile.in resets CXX to "" in TARGET_CONFIGURE_OPTS if
BR2_GCC_CROSS_CXX is not set to 'y'. However, when using an external
toolchain, BR2_GCC_CROSS_CXX is not set even if the toolchain has a
C++ cross-compiler.
This patch adds a new BR2_GCC_CROSS_CXX option in the external
toolchain configuration menu, so that just like BR2_INET_RPC,
BR2_INET_IPV6 and the others, it can be set according to the external
toolchain configuration.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix issues with binary external toolchains
Fix two problems encountered while using an external binary toolchain
generated by crosstool-ng:
- Don't remove the ending / in LIB_DIR, otherwise find $LIB_DIR
-maxdepth 1 doesn't find any file in the case LIB_DIR is a symbolic
link and not a directory.
For some reason, find -maxdepth 1 doesn't have the same behaviour
on directories and symbolic links. Demonstration:
$ mkdir foobar
$ touch foobar/t1
$ touch foobar/t2
$ ln -s foobar barfoo
$ find foobar -maxdepth 1 -name 't*'
foobar/t1
foobar/t2
$ find barfoo -maxdepth 1 -name 't*'
$ find barfoo/ -maxdepth 1 -name 't*'
barfoo/t1
barfoo/t2
* Make sure the libraries are writable, otherwise the strip operation
might fail. The library files may not be writable if the toolchain
is not writable (which may happen if one wants to prevent anyone
from overwriting the toolchain, which is done by crosstool-ng, for
example).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Improve external toolchain support
* Do not put kernel-headers in the dependencies of BASE_TARGETS in
the case where BR2_TOOLCHAIN_SOURCE is not y. The kernel headers
are already supposed to be part of the external toolchain, so
there's no need to download, extract and install them.
* In the configuration system, don't display the kernel headers
version selection list when an external toolchain is selected. This
is implemented by moving the source
"toolchain/kernel-headers/Config.in" inside the if
BR2_TOOLCHAIN_SOURCE in toolchain/Config.in.2.
* Change the description and help message of the BR2_LARGEFILE,
BR2_INET_IPV6, BR2_INET_RPC, and BR2_SOFT_FLOAT option in
toolchain/external-toolchain/Config.in. In the case of an external
toolchain, the semantic of these options is not to enable large
file support, IPV6 or RPC (since the toolchain is already compiled,
it has been decided previously). Their semantic is to let Buildroot
know about the characteristics of the external toolchain being
used.
As an improvement, we could guess these values automatically:
- for BR2_LARGEFILE, look at the value of __UCLIBC_HAS_LFS__ in
bits/uClibc_config.h in the libc headers directory.
- for BR2_INET_RPC, look at the value of __UCLIBC_HAS_RPC__ in the
same file
- for BR2_INET_IPV6, look at the value of __UCLIBC_HAS_IPV6__ in
the same file
- for BR2_SOFT_FLOAT, look at the output of $(CC) -v 2>&1 | grep
-- "--with-float=soft"
But I'm not sure how this would be possible, since these values are
used at configuration-time by other configuration options, not only
at build time.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
libpng used to have the 'png' Makefile alias, which some packages used
in their dependencies list.
With the move to Makefile.autotools.in this is now gone, so update the
packages to match.
