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/FileOrderInTarballsCloses#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>
... 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>
... 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>
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>
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 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>
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>
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>
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>
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>
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.
