This patch makes gdb benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes eglibc benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch promotes the PKGVERSION and BUGURL options to toolchain level so that
all toolchain components supporting them can benefit from them.
These options are passed to configure through --with-pkgversion and
--with-bugurl.
They are supported by binutils 2.18+, gcc 4.3+, eglibc 2.9+ and gdb 7.0+.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch adds a blind option CC_GCC_HAS_PKGVERSION_BUGURL to test the support
of --with-pkgversion and --with-bugurl by GCC's configure.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
kconfig bools are disabled by default, so specifying 'default n' is useless and
noisy. This patch removes all occurrences of 'default n'.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
If check_for is able to find the required prog/inc/lib, allow it to
set an arbitrary variable to 'y'. This variable is then pushed down
to the kconfig definition.
For example:
has_or_abort prog=foobar kconfig=has_foobar
If foobar is available, it yields a kconfig variable defaulting to y:
config CONFIGURE_has_foobar
bool
default y
If foobar is missing, it yields a kconfig variable defaulting to n:
config CONFIGURE_has_foobar
bool
Thus it is possible to depends on that variabel to show/hide options:
config SOME_FEATURE
bool
prompt "Some feature"
depends on CONFIGURE_has_foobar
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Update help entries for thos variables that accept multiple
arguments with spaces (aka. array-capable variables).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Make it explicit that a variable is an array bu the name of the variable.
It will be used later when .config gets munged to allow both multiple
arguments and arguments with spaces at the same time to be passed from the
configuration down to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Now that kconfig can include a file multiple times, link the glibc/eglibc
common stuff to two .in.2 files.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The latest kconfig stuff is more stringent when it comes to validating
the dependency of the symbols. It is no longer possible to have a symbol
depend on itself (such as our construct for arch/cc/libc/... was doing).
Fix our generated-file infrastructure to avoid these situations when the
new kconfig stuff will be merged (in a following changeset).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Since the gcc configuration changes, the way to select the
dependent companion libraries has changed. The addToolVersion
script was not updated to match, and a new gcc version was
added with this script.
Fix the gcc version; the script will be updated in a subsequent
changeset.
Reported-by: Xun Li <lxfind@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It can be quite confusing for a new-comer to find strange
version numbers for gdb, so hide the Linaro versions by
default.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Move options around so it feels more organised.
Add comments to separate groups of related options.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Re-organise the sub-menu so that:
- the kernels list comes first,
- followed by kernels generic options
- followed by kernels specific options
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Re-organise the sub-menu so that:
- the archs list comes first,
- followed by archs generic options
- followed by archs specific options
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In backend mode, setting the sysroot name is the
responsibility of the upper-layer build system.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Managing the shared version of the companion libraries
has become cumbersome.
Also, it will one day be possible to use the companion
libraries from the host distribution, and then we will
be able to easily use either shared or static libs.
As a side note, while working on the canadian-rework
series, it has become quite more complex to properly
handle shared companion libraries, as they need to be
built both for the build and gost systems. That's not
easy to handle. At all.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold can not build glibc/eglibc, force use of the BFD
linker during the toolchain build.
Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc. See this thread:
http://sourceware.org/ml/crossgcc/2011-04/msg00010.html
Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The gold linker does currently support only a limited set of architectures:
- x86 (32- and 64-bit)
- ARM
Hide the gold option for other architectures.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add support for building SPARC targeted toolchain.
With this patch I have built a working sparc V8 (32 toolchain).
Testing shows that not all gcc versions works well:
4.4.1 OK (kernel builds and the final kernel can boot)
4.4.2 Not tested
4.4.3 Not tested
4.4.4 BAD (Kernel can build but fails during boot)
4.4.5 BAD (Kernel can build but fails during boot)
4.5.1 BAD (Build fails with a spill related ICE - http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35664)
4.5.2 OK (kernel builds and boots)
I have successfully been using the 4.5.2 version for a few months.
This patch does not add support for the LEON variant.
That may come later.
Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
[yann.morin.1998@anciens.enib.fr: for 32-bit, default CT_TARGET_ARCH is OK]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
PPL 0.11+ installs three libs: lippl, libppl_c and libpwl.
libppl_c has a dependency on libpwl (at least for watchdog stuff).
While gcc correctly links with libppl and libppl_c, it does not
pull libpwl in. In case of shared libs, this is not a problem, as
libppl_c has a NEEDED dependency on libpwl. But for static libs,
that does not work. Although libppl_c.la exists and has a correct
dependency on lipwl, somehow gcc misses it. So we have to force
pulling libpwl when needed.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It can be quite confusing for a new-comer to find strange
version numbers for gcc, so hide the Linaro versions by
default.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Before gcc 4.6 was released, Linaro has a pre-release available.
Include that version in the config list.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
So far, we've had a version always select appropriate _or_later option,
which in turn would select all previous _or_later options.
Because the dependencies on companion libs were cumulative, that was
working OK. But the upcoming 4.6 will no longer depend on libelf, so
we can't keep the cumulative scheme we've been using so far.
Have each release family select the corresponding dependencies, instead
of relying on selecting previous _or_later.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
