When flex is built for the target without installing the
flex binary, a flex++ symlink installed by flex's Makefile
points to the missing flex executable. This mod adds
a post target install hook to remove the broken symlink.
Signed-off-by: Danomi Manchego <danomimanchego123@gmail.com>
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
The buildroot manual contains a list of deprecated items, with their config
title text, and the location in the config menu. If the config text does not
mention a package name, this can be confusing.
For example, the symbol BR2_PACKAGE_FLEX_BINARY has as text:
'Install tool in the target', which outside of the flex context makes no
sense at all.
To make sure the deprecated packages list in the manual is understandable,
rename the (deprecated) flex 'target binary' config option.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
In order to keep better track of when a feature got deprecated, and hence
when it can be removed, a new set of symbols BR2_DEPRECATED_SINCE_xxxx_xx is
introduced. These symbols are automatically selected when BR2_DEPRECATED is
selected, and thus are transparent to the user.
A deprecated feature will no longer depend on BR2_DEPRECATED directly, but
rather on the appropriate BR2_DEPRECATED_SINCE_xxxx_xx. If that symbol does
not yet exist, it has to be created in Config.in.
When removing a deprecated feature, one should also check whether this was
the last feature using the BR2_DEPRECATED_SINCE_xxxx_xx symbol, in which
case the latter can be removed from Config.in.
A followup patch will make sure the overview is added to the list of
deprecated features in the manual, so that a buildroot core developer can
easily determine which features to remove in a given development cycle.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since some time, we have removed the support to build a toolchain for
the target, and therefore the support for several development tools on
the target.
This commit deprecates a few additional development tools: m4, bison,
flex and gob2. For flex, we retain the ability to build libfl, we only
deprecated the ability to build the flex binary itself.
The original motivation for this patch is that m4 is causing build
issues in some configurations, but there isn't really much incentive
to fix this package for the target, since it is not really useful for
embedded Linux systems.
Bison, Flex and Gob2 are deprecated because they are reverse
dependencies of m4.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
When a package A depends on config option B and toolchain option C, then
the comment that is given when C is not fulfilled should also depend on B.
For example:
config BR2_PACKAGE_A
depends on BR2_B
depends on BR2_LARGEFILE
depends on BR2_WCHAR
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
This comment should actually be:
comment "A needs a toolchain w/ largefile, wchar"
depends on BR2_B
depends on !BR2_LARGEFILE || !BR2_WCHAR
or if possible (typically when B is a package config option declared in that
same Config.in file):
if BR2_B
comment "A needs a toolchain w/ largefile, wchar"
depends on !BR2_LARGEFILE || !BR2_WCHAR
[other config options depending on B]
endif
Otherwise, the comment would be visible even though the other dependencies
are not met.
This patch adds such missing dependencies, and changes existing such
dependencies from
depends on BR2_BASE_DEP && !BR2_TOOLCHAIN_USES_GLIBC
to
depends on BR2_BASE_DEP
depends on !BR2_TOOLCHAIN_USES_GLIBC
so that (positive) base dependencies are separate from the (negative)
toolchain dependencies. This strategy makes it easier to write such comments
(because one can simply copy the base dependency from the actual package
config option), but also avoids complex and long boolean expressions.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
(untested)
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
This patch lines up the comments in Config.in files that clarify which
toolchain options the package depends on.
Signed-off-by: Thomas De Schampheleire <thomas.de.schampheleire@gmail.com>
Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
Since fe6a9e5e9d (flex: needs M4 at runtime), the autobuilders have
been producing a number of flex related build failures. They have been
hard to track down, because even on the same machine, with the same
Git commit ID and the same configuration, the failure could not be
reproduced.
However, a close inspection of flex's config.log file allowed to find
out what the problem was. In its configure script, flex uses the
host-flex to generate a minimal example, and find out the name of the
output file of flex.
When the M4 environment is passed when building the target flex, it
also affects the *execution* of the host-flex, which tries to use
/usr/bin/m4 (which doesn't exist in the autobuilder machines) instead
of the one built in $(HOST_DIR)/usr/bin/m4. So generating the minimal
example fails. And this is where what I could reproduce and what the
autobuilders script produce differ: in my case, even though host-flex
fails to run, it creates an empty lex.yy.c, which is enough to make
the configure script happy. In the context of the autobuild scripts,
this file is apparently not created at all, for an unknown reason, and
this leads to the configure script to abort.
The fix is to set ac_cv_path_M4. This will affect the default m4 used
by the target flex, but it will not affect the m4 used by the
host-flex. It allows the test made during the configure script to work
properly, and therefore should fix the issue seen in the autobuilders.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
For proper runtime execution, flex requires m4 to be
installed. Passing a M4 variable at configure time is needed,
otherwise flex on the target will try to use a 'm4' binary with a
build machine path.
Fixes bug #4988.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
The flex binary uses fork() so it breaks on !MMU builds.
Since we usually don't require flex in the target and the common
scenario is that we just want libfl in staging reverse the options so
that BR2_PACKAGE_FLEX just builds and install libfl.a and change the
LIBFL option to BR2_PACKAGE_FLEX_BINARY to install the binary in the
target.
Signed-off-by: Gustavo Zacarias <gustavo@zacarias.com.ar>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
From now on, packages only need to select the BR2_PACKAGE_GETTEXT
option and depend on the 'gettext' package to get the necessary i18n
libraries installed on the target.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Tested-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
[yann.morin.1998@free.fr: remove BR2_PACKAGE_LIBINTL]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Tested-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Acked-by: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
CC: Samuel Martin <s.martin49@gmail.com>
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>
Flex doesn't NEED gettext/libintl, but it's configure script checks for it,
so make sure those a built before flex, otherwise flex will populate
tgt-config.cache with invalid values, breaking the build of other packages
needing it (like libglib2).
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Version 9 is no more available on Debian FTP.
Signed-off-by: Julien Boibessot <julien.boibessot@armadeus.com>
Signed-off-by: Peter Korsgaard <jacmet@sunsite.dk>
Flex contains a libfl.a directory, which programs for the target might
link against. Therefore, we need to install flex to the staging
directory. An example of such a program is gob2, which needs the
yywrap() function, which is implemented by libfl.
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Could not apply when missing top level Makefile, which is also
regenerated by the configure script.
Signed-off-by: Lionel Landwerlin <llandwerlin@gmail.com>
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>
they should be configured with --prefix=/usr and we then need to use
make DESTDIR=$(STAGING_DIR) install to get things installed into the
staging directory. The current situation for many packages, which use
--prefix=$(STAGING_DIR) results in the staging_dir paths getting compiled
into the binary itself.
This also adds in a pile of libtool fixups. Between broken pkgconfig,
broken libtool handling, and broken --prefix settings, its a wonder
things have worked as well as they have up till now.
-Erik
