| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add TARBALL_RESULT option that will produce a tarball of the final
toolchain to make it easier to deploy the toolchain to other machines.
The implementation uses `find | sort` instead of `tar --sort` because
this was introduced in GNU Tar v1.28, which is not available in some LTS
Linux distributions. This is a variation of the command recommended
here: https://wiki.debian.org/ReproducibleBuilds/FileOrderInTarballs
Closes #1262
Signed-off-by: Chris Packham <judge.packham@gmail.com>
|
|
|
|
|
|
|
|
|
|
| |
Fixes: #887
On some systems the file command identifies a pie executable as a shared
object. Update do_finish() to handle this case so that they are stripped
as well.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
|
|
|
|
|
|
|
| |
... so that ar can find the plugin even when invoked directly, not
via the gcc-ar plugin.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
| |
Signed-off-by: Alexey Neyman <stilor@att.net>
|
| |
|
|
|
|
|
|
| |
Also, add a poor man's upgrade script.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
| |
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... enabled by default for multilib and disabled otherwise. Buildroot
has been complaining about /etc/ld.so.conf presence for almost a year
now and I missed that.
After the release, xldd will be modified to query the compiler for
the list of multilibs to search. This would be too invasive change
before 1.23, though.
Note that it may lead to configurations where xldd currently does not
find the libraries (if both DEMULTILIB and CREATE_LDSO_CONF are turned
off). This is not the default setting in Kconfig, though.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
| |
Also a fix for CT_IterateMultilibs: it didn't pass multi_os_dir_gcc, so
it only worked if the caller did *not* declare it as a local variable.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
|
| |
... and in addition to final toolchain aliasing, use it when configuring
multilibs for glibc/musl. Note that uClibc does not need it, it is
explicitly selecting the tools using CROSS_PREFIX.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
| |
Check for FreeBSD specific issues, it is mostly the same as Darwin.
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
|
|
|
|
| |
This reverts commit 7bcf18bfab84374d3305c7a088f95ac1219ddf93.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
... and then use the right option. See the note in scripts/functions
on where we should use ${foo} and where just 'foo'; this boils down to
whether we can expect the build tools override to be in effect (e.g. in
the actual build scripts) or not (i.e. outside of scripts/build).
While running in scripts/functions, or in scripts/crosstool-NG.sh the
build tools override directory (.build/tools/bin) may have not been
set up (yet, or at all).
Also, modify the installed scripts (populate, xldd) accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The referenced commit replaced 'make' with '${make}' everywhere. This is
wrong for at least the utilities that we may build as companion tools
(make, libtool): this will always invoke the version detected by configure
by supplying the absolute path. In other words, the wrappers in
.build/tools/bin are not fallbacks - they are either temporary (in case
a respective companion tool is built) or permanent redirectors.
This is the reason why the PATH= has .build/*/buildtools/bin at higher
precedence than .build/tools/bin; the latter has the versions detected by
configure and the former has the versions built as companion tools.
Revert the rest of the gang (grep/sed/...) for consistency. After all,
we may decide to supply some of them as well (awk, for instance).
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
| |
On mingw target gdbserver is suffixed with '.exe', thus
plain 'strip gdbserver' fails.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
|
|\
| |
| | |
populate: Fix undefined awk
|
| |
| |
| |
| | |
Fix minor issue introduced by 6f8e89cb5ca061e899bf3feaaf3fecf30d366c3e
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For 4 different folders:
${CT_PREFIX_DIR}
${CT_SYSROOT_DIR}
${CT_SYSROOT_DIR}/usr
${CT_PREFIX_DIR}/${CT_TARGET}
.. symlinks from 'lib32' and 'lib64' to 'lib' were created.
This was untidy and incorrect for multilib (the bitness of
the libraries in 'lib32' and 'lib64' will not be the same)
We can not know which folders this toolchain configuration
will require at this time so let them be created on-demand
instead.
Changed by Alexey Neyman: original change removed too much; we
still need to create the default directories because the os
directories are based off them (e.g. `lib/../lib64').
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We check for apps:
* make
* sed
* grep
* awk
* libtool/libtoolize
* install
* patch
* and more
...during configure. Our scripts should be consistent about using the
variables that define where the found tool was found.
Of course, we do hard-link these tools in buildtools, but that should be
a backup for the components we are building. Our scripts should always
use the tools we find.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This change updates the CC.* references to CC_GCC.* in the internal
scripts.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
|
|
|
|
|
|
|
|
| |
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
[yann.morin.1998@free.fr: quote variables]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <CACgzC7BU9CPZ2cE+EYqnMe2WNz-wYby6f4tsmjJi715WmPmbWw@mail.gmail.com>
PatchWork-Id: 185303
|
|
|
|
| |
Signed-off-by: Zhenqiang Chen <zhenqiang.chen@linaro.org>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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>
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix typo introduced by changeset #055e505f28be.
Also, handle older versions of gcc (typically, all versions
prior to 4.0.0).
Maxime provided a similar patch, missing the case for the
legacy versions of gcc.
Reported-by: Maxime Bizon <mbizon@freebox.fr>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
| |
We can't run the newly built gcc when it is a canadian cross.
Thus, we can't get the version number, and thus we can't get
the directory libexec subdirectory to strip.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
gcc installs the C++ headers in ${PREFIX}/include/ but we trash
that directory at the end of the build.
We previously removed that directory as it contained the companion
libraries header files. But it's been some time now that we isntall
the companion libraries in their own dedicated place, so we do not
need to remove that directory.
Until we have a better fix, just keep that directory for now.
Reported-by: Bob Rossi <bob@brasko.net>
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>
|
|
|
|
|
|
|
|
|
| |
Some scripts have 'very long lines', so the output of 'file'
will have that mentioned, such as:
POSIX shell script, ASCII text executable, with very long lines
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
| |
The heuristic to find shell script is deficient. Fix it.
Reported-by: Kyle Grieb <grieb.kyle@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
| |
The lib64 symlinks are needed for the linker to find the libraries.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
|
|
| |
The gcc used by linaro has a version number specific to Linaro, but
identifies itself with its upstream version numbering scheme.
This breaks the strip in the finish step, because the actual gcc version
is not the same as the configured one (eg. 4.5.2 vs. linaro-4.5-2011.02-0).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
| |
Part of the installed doc was not removed (if configured to).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
|
|
|
| |
Do not try to strip any script.
Previously, only shell scripts were ignored, but when the Java frontend
is installed, it also installs a Python script. So we have to ignore
any "script text executable", and not restrict it to "shell script text
executable".
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
| |
Using a list of files to strip misses a few of them.
Now, scan appropriate directories, and strip all ELF
executables and shared objects.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
| |
For 32-bit target systems, report 4-byte (8-xdigit) wide adresses,
and for 64-bit, report 8-byte (16-xdigit) wide adresses.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
| |
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
| |
The version string was hard-coded.
Now, the version string follows the crosstool-NG version.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Do not provide the PREFIX/TUPLE/include -> SYSROOT/usr/include symlink,
and let gcc install its dependable C++ headers were it sees fit to
install them.
See the test by Anthony (by the end of the messages):
http://sourceware.org/ml/crossgcc/2010-10/msg00129.html
http://sourceware.org/ml/crossgcc/2010-10/msg00134.html
See also the comment by Arnaud:
http://sourceware.org/ml/crossgcc/2010-10/msg00157.html
Reported-by: Anthony Foiani <anthony.foiani@gmail.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
|
|
|
|
| |
The symlinks are needed only during the build process.
The final gcc will still search those dirs, but will also search
the standard lib/ dirs, so we can get rid of the symlinks.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
|
|
|
|
| |
strip on CT_HOST darwin does not want --strip-all or -v
|
|
|
|
|
|
|
|
|
|
| |
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 a cross-ldd that mimicks a native ldd.
|
|
|
|
|
| |
If the sed expression does not transform the
tuple, do not try to create the symlink.
|
|
|
|
|
|
| |
static linking is not possible on MacOS, and unnessecary on other systems.
The old optimization and warning flags crash the gcc on MacOS
and (imho) are a bit overdone for this software.
|
|
|
|
|
|
|
|
| |
The shell wrapper script uses a nonportable call to readlink.
Thus, always use the binary wrapper under BSD/MacOS.
yann.morin.1998@anciens.enib.fr:
Use 'case' instead of 'if'.
|
|
|
|
|
|
|
|
| |
The call to stat to find out if a file is a symlink works only on GNU systems,
and the replacing portable call to readlink is also shorter and more concise code.
yann.morin.1998@anciens.enib.fr:
Apply simpler test, after discussion with author and Arnaud LACOMBE on the ML.
|
|
|
|
|
| |
After the toolchain is built, we do no longer need the headers.
Reported-by: Enrico Weigelt <weigelt@metux.de>
|
|
|
|
|
|
| |
Remove the build tools only after the wrapper is built.
Use the corect C compiler to build the tools wrapper.
Use the correct log level.
|