The host build of icu doesn't need to build everything, so we can add
a few more --disable-<foo> options to save a little bit of build time.
On a fast build server, this bring the host icu build from 2m28.517s
to 2m5.192s.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
When passed --enable-static and --enable-shared, icu will generate
both a shared and a static version of its libraries.
However, in order to do so, it builds each and every object file
twice: once with -fPIC (for the shared library), and once without
-fPIC (for the static library). While admittedly building -fPIC for a
static library generates a slightly suboptimal code, this is what all
the autotools-based project are doing. They build each object file
once, and they use it for both the static and shared libraries.
icu builds the object files for the shared library as .o files, and
the object files for static library as .ao files. By simply changing
the suffix of object files used for static libraries to ".o", we tell
icu to use the ones built for the shared library (i.e, with -fPIC),
and avoid the double build of icu.
On a fast build server, this brings the target icu build from
3m41.302s down to 1m43.926s (approximate numbers: some other builds
are running on the system at the same time).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Many of ARM Sourcery CodeBench toolchain have a bug when compiling
icu's translit.cpp source file. The bug is trigerred when there is a
combination of "-W -Wall" and "-Os", and causes an internal compiler
error. The bug has been reported to Mentor Graphics.
Even though it is clearly a toolchain bug, having a workaround for it
is trivial in this case. So it will avoid our users falling into this
internal compiler error, and allow our autobuilders to test more
packages using this Sourcery CodeBench toolchain.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Use the <pkg>_CONFIG_SCRIPTS mechanism in all packages for which it
does all what the package was doing. A few packages, like libxslt, are
for now left out, since they need some additional fixup (for example a
fixup of includedir).
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Thanks to the pkgparentdir and pkgname functions, we can rewrite the
AUTOTARGETS macro in a way that avoids the need for each package to
repeat its name and the directory in which it is present.
[Peter: pkgdir->pkgparentdir]
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The icu build system seems to have a race condition, which gets triggered
by high BR2_JLEVEL settings, so disable parallel builds.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Closes#3259
We need to tweak icu-config's exec_prefix too, otherwise if the host
system lacks icu the build fails when looking for the libraries in
/usr/lib rather than the staging directory.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Now that TARGET_CXX contains a --sysroot= option and therefore spaces,
it needs to be used with quotes.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Fix two issues with the icu build:
- icu source contains an #elif without any arguments, which g++ >= 4.4
flags as an error. This is both an issue for target and host build,
so restructure the .mk so any *both*patch is applied to both builds
(the other patches would cause trouble with host builds)
- icu build system isn't parallel make safe, use MAKE1
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
We have been passing -q to ./configure when using 'make -s' for
packages using Makefile.autotools.in for some time. Do the same
for packages using autotools, but not using the
Makefile.autotools.in infrastructure, taking care to not do it
for packages with hand written configure scripts.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
A C library will have been built by the toolchain makefiles, so there is no
need for packages to explicitly depend on uclibc.
Signed-off-by: Will Newton <will.newton@gmail.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
