Instead, prepare the files as a part of bootstrap and install them.
This avoids rebuilding these files in each working directory; they
don't change anyway as they are generated from the same installed
source.
Signed-off-by: Alexey Neyman <stilor@att.net>
Building with CT_MINGW_TOOLS unset before this change produces:
/usr/local/ct-ng/lib/crosstool-ng-1.23.0-rc2/scripts/build/libc/mingw.sh: line 212: [: =: unary operator expected
Check for python2/python3 and if found, pass them to --with-python.
Allow user to override the choice via a new config option. This
fixes systems where there is no "python", only "python2" or "python3".
Signed-off-by: Alexey Neyman <stilor@att.net>
If the build machine lacks tic, we need to build it in the first pass
even if host==build: ncurses Makefiles are not smart enough to build
'tic' first and use the just-built tic to compile fallback terminfo.
Signed-off-by: Alexey Neyman <stilor@att.net>
On cygwin, creating both "foo.exe" and "foo" results in 'ln -sf'
returning an error ("File exists"). However, ln silently removes
the "foo.exe" in this case, so an attempt to re-run the same command
manually then succeeds.
Hence, make binutils.sh also create symlinks with .exe prefix,
using the new & shiny routine.
Signed-off-by: Alexey Neyman <stilor@att.net>
- libpthread requires iteration over multilibs, unlike the core, it
does not detect and build multilibs by itself.
- Disable parallel builds for mingw-w64 components; until mingw-w64 core
builds clean, I am not trusting it.
- Make the list of tools to build configurable
- Turn on multilib in x86_64 sample.
- Make warnings about tuple less redundant. As in, "one WARN is enough,
no need to shout it three times".
- Messages about various steps/substeps are more aligned with the rest
of the components.
- Use 'make' instead of ${make} to invoke the companion make just built,
if applicable.
Signed-off-by: Alexey Neyman <stilor@att.net>
... when determining if it can be linked statically, and if Python
scripting should default to y.
Prompted by a failure of i686-w64-mingw32,nios2-spico-elf sample
on a system where configure didn't report static linking support.
Signed-off-by: Alexey Neyman <stilor@att.net>
(see the comments in the code for details on the issue)
Old workaround in 100-gcc.sh stopped working (probably, due to one
of GCC version upgrades), so switch to the other approach originally
described there: adjust the list of multilibs to not include the
default target explicitly.
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>
It turns out buildroot does not currently accept a toolchain where a dynamic
linker does not reside in the multi-os-directory. Unfortunately this is
how glibc installs itself on AArch64 without any extra tricks.
So, provide an option to force everything into /lib or /usr/lib; patch to
buildroot will be worked on separately.
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>
Convert absolute targets to relative so that they are valid on the host,
too. The procedure is very similar to uclibc, so it is moved into a
common function.
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>
make's configure uses pkg-config to detect if Guile should be enabled;
on ArchLinux, this picks up Guile from build machine's pkgconfig and then
it fails to compile.
A better solution might be to create a ${CT_HOST}-pkg-config in
buildtools/bin that would report "unsupported" for all packages.
However a quick grep only showed pkg-config being used by GCJ
(not sure if it will build in canadian cross - we don't have any
samples with GCJ) and Blackfin simulator in GDB (Blackfin is not
currently supported by crosstool-ng). Hence, leave such pkg-config
implementation and testing for another day.
Signed-off-by: Alexey Neyman <stilor@att.net>
It picks up gettext string and results in [ERROR] messages from ct-ng
when gettext strings happen inside an error() call.
Signed-off-by: Alexey Neyman <stilor@att.net>
--enable-hacker-mode is not sufficient, in 2.25 configure then
fails while checking for sysdeps fragments that apply to a given
configuration, and with that worked around, fails on binutils &
compiler version check.
In brief: if someone wants locales on cygwin/macos, you'd have to
implement cross-localedef (similar to cross-rpcgen) in glibc and
submit it upstream.
Signed-off-by: Alexey Neyman <stilor@att.net>
The latter does not prevent zlib's configure from overriding 'AR' with
/usr/bin/libtool on macos, and that breaks canadian crosses.
Signed-off-by: Alexey Neyman <stilor@att.net>
GMP's configure script tries to be too smart, and if it determines
that it's not cross-compiling it chooses gcc or cc instead of the
wrapper we create at the start of the build.
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
If glibc's configure finds the host c++ executable it assumes that
c++ should be enabled for the build. In case we don't have cross g++
built yet (ie, for headers), this causes the build to fail creating
C++ headers. So hide C++ from the build.
Signed-off-by: Dan McGregor <dan.mcgregor@usask.ca>
