Installing samples was not installing the C library config file
and the reported.by description.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Samples should contain kconfig-parsable definitions, not script variables.
.config.2 contains bash arrays, which is definitely not kconfig-safe...
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some archives like those of the 2011.07 revisions of Linaro GCC contain a folder
name different from the archive basename, which leads to errors afterwards, e.g.
when patching. E.g.:
gcc-linaro-4.5-2011.07.tar.bz2 extracts to gcc-linaro-4.5-2011.07-0/
This patch changes CT_Extract() to force the extraction of all archives to a
folder named like the archive basename. E.g.:
gcc-linaro-4.5-2011.07.tar.bz2 now extracts to gcc-linaro-4.5-2011.07/
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Currently, no --enable-add-ons option is passed to libc configure when
"$(do_libc_add_ons_list ,)" is empty, which makes configure automatically search
for present add-ons. In that case, all present add-ons are built, although
no add-on was selected by the user in the config. Moreover, this can make the
configure fail if some non-standard add-ons like eglibc-localedef are present.
This behavior also leads to an inconsistency from a user point of view between
the following cases:
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS="none" in the config,
which makes "$(do_libc_add_ons_list ,)" return "", so all present add-ons
are built.
- LIBC_ADDONS_LIST="", LIBC_GLIBC_USE_PORTS=n and THREADS!="none" in the
config, which makes "$(do_libc_add_ons_list ,)" return the add-on supporting
the chosen threading implementation, e.g. "nptl", so only this add-on is
built.
This patch disables the building of all add-ons in that case.
It is still possible to build all present add-ons by adding --enable-add-ons to
LIBC_GLIBC_EXTRA_CONFIG_ARRAY.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
This patch bumps the Linaro GCC revisions to 2011.07 when applicable.
Note that the `-0' suffix has been removed from the Linaro versioning scheme
beginning with this version.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
gdb needs to know where to find the libstdc++ helper python script
to do, well, whatever it has to do with it...
We can't install that in the user's ~/.gdbinit, it's too complex to
handle all the cases. Moreover, if the user is using more than one
toolchain, we can't put all that stuff in there...
Just provide a sample config file the user can adapt to his/her
own needs.
Thanks go to Khem RAJ for providing such a hint:
http://sourceware.org/ml/crossgcc/2011-07/msg00026.html
Reported-by: ANDY KENNEDY <ANDY.KENNEDY@adtran.com>
CC: Khem Raj <raj.khem@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The place to get 3.x has changed; the version scheme has changed.
No need to be overkill, just support 3.x; 4.x is not even dreamt of.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If the user builds a toolchain over an existing one, so, without removing
CT_PREFIX_DIR, the build fails as the symlinks already exist, as does the
build.log.
This can also happen (for build.log) if the user first ran in download-
or extract-only.
Patch (with no SoB) originally from:
Phil Wilshire <phil.wilshire@overturenetworks.com>
Modified by me as it did not apply cleanly.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
During the build, we create lib{32,64}/ symlinks out of the sysroot.
In some cases (eg. mingw32 target), these symlinks are still required
when running the toolchain. For other combinations, the symlinks are
without incidence, so they can be safely kept after the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In case there's one lingering around (whether the previous build was
successful, or failed), we have to remove the buildtools directory
as well as the toochain build dir.
This should also fix the case where out makeinfo wrapper calls
itself recursively.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Maintaining thos multi-line shell commands in a Makefile rule is
a real PITA.
Move the two affected rules (build_gen_choice_in and build_gen_menu_in
to a shell script.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
cvs is used to get newlib directly from its repository. Missing cvs
will only allow getting newlib from the released tarballs.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
It is useful to sometime run on a strictly POSIX-compliant
shell... :-/
And it is sometime interesting to refresh Q-patches before
finishing the series... :-(
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The new MIPS-specific options are not valid for other targets.
Also, move the arch-specific setting lower in the extra_config setting.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Rather than building all possible library names in the caller,
lets just do it once in check_for.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Static liunking is not supported on Darwin, so hide the corresponding
options when the build machine is Darwin.
Reported-by: Andrea Franceschini <therealmorpheu5@gmail.com>
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reported-by: "Titus von Boxberg" <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Indent the error/warning message so that it is explicit that
the second line is giving details for the first general hint.
Reported-by: Titus von Boxberg <titus@v9g.de>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add the following MIPS specific options when configuring gcc:
--with(out)-llsc
--with(out)-synci
--with(out)-mips-plt
--with-divide=type
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to specify the hash type that gcc will ask the linker to use.
It is a provision for the upcoming 4.7, as no version currently supports it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add an option to configure gcc with --enable-linker-build-id.
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Instead of getting eglibc over standard svn://svn.eglibc.org
Add an option that allows the user to get source from
http://www.eglibc.org/svn
This is useful if you are behind a firewall or proxy.
If you are behind a proxy, don't forget to configure
${HOME}/.subversion/servers
In the [global] section setup your proxy configuration.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
[yann.morin.1998@anciens.enib.fr: removed useless 'default n']
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
That option is coming from the original crosstool, and is not entirely
understand here.
Moreover, it breaks with newer gcc-s: 4.6.1 now breaks while configuring
libjava (and probably some other libs as well, untested).
There is an related bug report to the gcc BZ:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49555
If need be, the old behavior can be restored with:
CC_CORE_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
CC_EXTRA_CONFIG_ARRAY="--enable-symver=gnu"
Reported-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The patchset was obtained by dumping each changeset on the
upstream 0.9.32 branch since the release:
git log v0.9.32..origin/0.9.32 |sed -r -e '/^commit/!d; s/.* //;' |tac
and then creating a patch from each changeset.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
