Some configure scripts seems to ignore CXX settings if it is set to
the empty string, and goes back to the default (<arch>-linux-g++),
so use false instead, as that will loudly break the build if the
C++ compiler is ever used.
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Change the definition of TARGET_LDFLAGS to use --sysroot
$(STAGING_DIR) instead of -L$(STAGING_DIR)/lib
-L$(STAGING_DIR)/usr/lib. It fixes the following failure while trying
to build mtd-utils :
/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/bin/arm-unknown-linux-uclibcgnueabi-gcc -L/home/thomas/local/buildroot-output/build_arm/staging_dir/lib -L/home/thomas/local/buildroot-output/build_arm/staging_dir/usr/lib -o /home/thomas/local/buildroot-output/build_arm/mtd_orig/flash_eraseall /home/thomas/local/buildroot-output/build_arm/mtd_orig/crc32.o /home/thomas/local/buildroot-output/build_arm/mtd_orig/flash_eraseall.o
/usr/local/xtools/arm-unknown-linux-uclibcgnueabi/lib/gcc/arm-unknown-linux-uclibcgnueabi/4.3.2/../../../../arm-unknown-linux-uclibcgnueabi/bin/ld: cannot find /lib/libc.so.0
collect2: ld returned 1 exit status
make[1]: *** [/home/thomas/local/buildroot-output/build_arm/mtd_orig/flash_eraseall] Error 1
At the same time, simplify the definition of TARGET_CFLAGS, because
the -I$(STAGING_DIR)/include -I$(STAGING_DIR)/usr/include
-I$(TOOLCHAIN_EXTERNAL_PATH)/$(TOOLCHAIN_EXTERNAL_PREFIX)/include are
no longer necessary since we sysroot the toolchain in $(SYSROOT_DIR).
This patch has no effect on non-external toolchain builds.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Move stamp (dependency) files outside the (version specific) source
directories, so other packages can hardcode dependencies on them instead
of having to use <PACKAGE>_VERSION variables.
This is important as the variables in the make rules are evaluated when
the rules is seen, which might be before the dependent makefile is parsed
(and hence <PACKAGE>_VERSION variable is known, screwing up stuff.
The downside of this is that the package isn't automatically rebuilt
when the version changes (E.G. by a svn update) and you now also have to
remove the stamp files next to $(BUILD_DIR)/<PACKAGE>-* to force a rebuild.
This matches upstream tarball, doesn't screw up existing .config's with
BR2_PACKAGE_PKGCONFIG and makes sure the patch gets applied for target
compilation.
gcc < 4.2.0 doesn't support -Wno-overlength-stings, but gcc-4.3.x configure
fails to detect that, breaking the build.
Work around it by detecting the host gcc version (and store in HOSTCC_VERSION)
and set the proper configure variables for gcc < 4.2.0.
The VFP is only available for a few ARM CPUs at the moment,
so this breaks the liboil build.
A patch is available upstream which only enables "-mfpu=vfp"
if "--enable-vfp" is given to "configure".
Autotools needs to be run for liboil for this to take effect.
A new configuration BR2_VFP_FLOAT is added to allow enabling vfp.
If this is "yes", then "-mfpu=vfp" is added to CFLAGS.
TARGET_PATH didn't contain $(STAGING_DIR)/usr/bin, which means that
programs installed in $(STAGING_DIR)/usr/bin were not considered for
execution during Buildroot build process. This was a problem with host
automake/autoconf/libtool, which could not be found.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
* In toolchain/external-toolchain/ext-tool.mk, copy the contents of
the sysroot directory to the staging dir.
* In package/Makefile.in, add a --sysroot CFLAGS pointing to the
staging dir
* Remove the CFLAGS and LDFLAGS definition from
TARGET_CONFIGURE_OPTS. I haven't investigated exactly why, but with
these options, DirectFB fails to build because it cannot find
PTHREAD_RECURSIVE_MUTEX_INITIALIZER_NP, even if DirectFB's Makefile
properly sets -D_GNU_SOURCE.
I have already sent this patch on December, 2nd to the mailing-list,
but got no feedback. So let's commit and see what happens :-)
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The following changes allow for use of a central configure cache
file. This speeds up configuration of packages.
Its use is configurable at the top level (BR2_CONFIG_CACHE - default n).
Old style makefiles can use it if they use the following MACRO in makefiles:
$(AUTO_CONFIGURE_TARGET) see my change to directfb.mk.
New style Autotools.in will use it if you set the global option.
However you can enable the global option and on a per package overrule it by doing
the following: $(PKGNAME)_USE_CONFIG_CACHE = NO see fontconfig.mk for an example
of this.
Finally I have removed a few config variable settings which indicated no CXX compiler
as this is wrong and breaks the build when using this central cache.
Config.in | 8 ++++++++
package/Makefile.autotools.in | 5 ++++-
package/Makefile.in | 28 +++++++++++++++++++++++++++-
package/atk/atk.mk | 2 +-
package/directfb/directfb.mk | 7 +------
package/fontconfig/fontconfig.mk | 3 +++
package/libglib2/libglib2.mk | 2 +-
package/libgtk2/libgtk2.mk | 1 -
8 files changed, 45 insertions(+), 11 deletions(-)
I would appreciate feedback on this change (I have been testing for 2-3 weeks)
But I can never test all cases! If you enable the BR2_CONFIG_CACHE option some
Makefile.autotools.in based packages may now break - I cannot build them all.
In this case you may need to remove config options that are being hardcoded all
over the place (like gtk saying we have 2 CXX compiler) or disable the use
of CONFIG CACHE file like I have done in fontconfig.
I can build all packages required to get WebKit on DirectFB up and running
and it runs fine.
I will try to resolve any issues this creates as fast as I can.
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.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>
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>
As per various email discussions add -rpath-link
to the LDFLAGS.
This definately fixes a few issues for Thomas and myself
Any objections and it can be pulled again.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@...>
Signed-off-by: Daniel Laird <daniel.j.laird@nxp.com>
Upgrade to pkgconfig 0.23 which has native sysroot support (buggy,
but easily fixable), which allows us to get rid of pkgconfig-filter.sh.
At the same time cleanup the makefile.
