Transfrom array variables from pure strings (in the kconfig output)
into proper bash arrays declarations, for feeding to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
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>
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>
Users tend to look for the build log in the current working directory,
rather than in the toolchain's installation dir. While bundling the build
log in the toolchain installation dir is nice for distribution and review,
it can be easier to have the build log readily available in the working
directory, as it is quicker to get to it.
So, the build log stays in the working directory until the toolchain is
completely and successfully built, and then a (compressed) copy is made.
Reported-by: Trevor Woerner <twoerner@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Consider the buildtools install directory as a prefix directory,
that is, install buildtools in prefix/bin/, not in prefix/.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
There is absolutely *no* reason for the buildtools (wrappers to gcc, g++,
as, ld... for the local machine) to be in the toolchain directory. Moreover,
they are removed after the build completes.
Move them out of the toolchain directory, and into the build directory (but
yet the part specific to the current toolchain). This means we no longer
need to explicitly remove them either, BTW, but we need to save/restore them
for the restart feature.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Currently, the buildtools are installed relative to ${CT_PREFIX_DIR}.
Change that by introducing ${CT_BUILDTOOLS_DIR}, which is
still set relative to ${CT_PREFIX_DIR}, but which will make it easy
to change in the future.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
If we set PATH to the tools wrappers before we create the
makeinfo wrapper, then we may well wrap an existing wrapper
from a previous run.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
In certain circumstances, removing the destination/installation directory
is a bad idea. For example, when the build environment is already taking
care of sanitising the build tree, and pre-installs stuff in there, it is
a very bad idea to remove the destination directory.
This happens now in buildroot, as the crostool-NG backend now installs the
toolchain in the common host-tools directory, and pre-install there a few
host-utilities (eg. host-automake and host-gawk).
Provide a config knob to turn on/off the removal of the destination
directory, defaulting to 'y' (previous behavior), and forced to 'n' when
used as a backend.
Reported-by: Peter Korsgaard <jacmet@sunsite.dk>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Computed paths may contain double slashes.
This is not an issue but it is just ugly to look at.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Depending on local policies, some users have expressed a need to
have the sysroot be named differently than the hard-coded name.
Add an option for that.
Default to 'sysroot' to match the existing literature.
While at it, replace 'sys-root' with 'sysroot' everywhere we
reference the sysroot.
Reported-by: Alexey Kuznetsov <Alexey.KUZNETSOV@youtransactor.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The reunification of the glibc/eglibc code paths exposed a nasty
bug in the glibc build: use of PARALLELMFLAGS breaks the build.
See the explanations in that bug report against FC6:
https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=212111
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
On some systems, we also need to overide LANG as well as LC_ALL.
Reported-by: Geoffrey Lee <geoffl@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Unconditionally create the lib32 -> lib/ and lib64 -> lib/ symlinks.
This is reportedly a fix to build a toolchain for a 32-bit target on
a 'pure' 64-bit host (eg. on Fedora FC12, host libs are in lib64/,
and there is no lib -> lib64 symlink, as we can see on other distors,
as Debian). As gcc only puts static host lib in lib64/ (along with
target files in subdirs), we can safely create the symlinks.
Also note that the symlinks are summarily removed at the end
of the build.
Signed-off-by: Anthony Foiani <anthony.foiani@gmail.com>
[Yann E. MORIN: fix a comment, rephrase the commit log]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Some archs (eg. ppc64 with n32 ABI) will install their
variants in lib32/ instead of lib/, so do for lib32 as
we do for lib64->lib symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
To reduce filesizes of the toolchain and even improve build times
of projects to be build with this toolchain it is usefull to strip
the delivered toolchain executables. Since it is not likely that we
will debug the toolchain executables itself we do not need the
debug information inside the executables itself.
Signed-off-by: Remy Bohmer <linux@bohmer.net>
Add CT_SanitizePath function which removes entries referring to ., /tmp
and non-existing directories from $PATH, and call it early in the
build script.
If . is in PATH, gcc-4.4.4 build breaks:
[ALL ] checking what assembler to use...
/tmp/build/targets/arm-unknown-linux-uclibcgnueabi/build/gcc-core-static/arm-unknown-linux-uclibcgnueabi/bin/as
...
[ALL ] config.status: creating as
i.e. "as" is supposed to be the arm-unknown-linux-uclibcgnueabi cross assembler,
but config.status creates a local "as" script which is calling the
host assembler.
Signed-off-by: Johannes Stezenbach <js@sig21.net>
[Yann E. MORIN: style fixes + explanations]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch adds support for installing the gcc test suite. A helper
Makefile is provided for building and running the gcc tests.
The default configuration runs all gcc tests and requires automatic
ssh/scp login access to a networked target board. See README for
more details.
Note: Current feature is tested with the powerpc-unknown-linux-gnu
sample but it should work with others as well.
Signed-off-by: Martin Lund <mgl@doredevelopment.dk>
On 64bit MacOS `gcc -dumpmachine` gives i686 for the host machine.
This conflicts with the expectations of some following configure scripts
that a 64bit x86 is given as x86_64; i686 is understood as a 32 bit machine.
config.guess sets the host machine in CT_BUILD correctly.
yann.morin.1998@anciens.enib.fr:
As suggested by Khem RAJ on the ML, always use config.guess.
On non-GNU systems (BSD/MacOS) there is no uname -o.
Suppress the failure message on these systems in the
call to set CT_SYS_OS (uname -s actually sets this variable).
yann.morin.1998@anciens.enib.fr: remove 'uname -o' altogether.
g++ is only needed when building additonal libs on the HOST,
so check wheter g++ is available for the HOST compiler only
Signed-off-by: Bart vdr. Meulen <bartvdrmeulen@gmail.com>
[Yann E. MORIN: fix space damage]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
It's broken anyway. Eg.:
- user is already niced at 10
- user configures to renice at 5
- breaks because user is not allowed to 'boost' his/her nice value
Bette let the user handle the renice with:
nice -XX ct-ng 'action'
Initial version of adding autoconf as a companion tool.
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: use generic overide tools dir]
[yann.morin.1998@anciens.enib.fr: update menu entries]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Change the overide bin dir so it can be used by companion tools
Signed-off-by: Richard Strand <richard.strand@icomera.com>
[yann.morin.1998@anciens.enib.fr: more generic overide tools dir]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The user shall provide a directory to install the toolchain into.
If he/she does not, this is an error, and shall be detected properly,
rather than relying on failure down the road.
Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out
the issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html
Warn about a missing local tarball directory, only if it was configured.
Avoid the spurious message:
Directory '${CT_LOCAL_TARBALLS_DIR}' does not exist.
Will not save downloaded tarballs to local storage.
Thanks to "Pedro I. Sanchez" <psanchez@colcan.ca> for pointing out the
issue:
http://sourceware.org/ml/crossgcc/2009-12/msg00011.html
In case the shell the user wants to use as CONFIG_SHELL is located in a
weird place (eg. /opt/bash/bin/bash), or is weirdly named (eg. bash-4),
let the user enter the patch to the shell.
