While here, also consider patched by anything other than "bundled patches"
as per-target sources. Add scary warnings in case of a failure.
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>
... 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>
--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>
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>
... 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>
... by passing BUILD_LDFLAGS twice (the 2nd argument overrides the first).
Also, no need to pass -I/-L for BUILD_CFLAGS/LDFLAGS, they are already included
by crosstool-NG.sh (but keep for BUILD_CPPFLAGS, as we set it up here).
Remove -Wl,-Bstatic/-Wl,-Bdynamic (we only build static complibs).
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>
Up until cset 4e2227e8a5 there was an 'if'
statement with a comment. The abovementioned changeset removed the
conditional statement but the comment survived.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
'ld' does not search for dependency libraries in multi_os_directory, so
if there's both multi_os_directory and multi_root, and there is only one
configuration in each multi_root, forgo the multi_os_directory suffix.
Needed for sh4-multilib-linux-uclibc.
Signed-off-by: Alexey Neyman <stilor@att.net>
Rather than echo-ing the new value, set the value into the variable with
the name passed as an argument (similar to CT_SanitizeVarDir). This
allows to use CT_DoLog in these functions.
Signed-off-by: Alexey Neyman <stilor@att.net>
This step was only used in uClibc. However, with upcoming multilib, the
config management will have to be done for each variant differently,
anyway.
uClibc was the only user of libc_check_config step, as well as
CT_CONFIG_DIR directory. Retire these.
Two other clean-ups in uClibc.sh:
- KERNEL_HEADERS check seems to be bogus, this config option is not
present even in 0.9.30 - which is not supported already.
- SHARED_LIB_LOADER_PREFIX was renamed to MULTILIB_DIR in 0.9.31,
according to ChangeLog - and MULTILIB_DIR is passed from command line
instead.
Signed-off-by: Alexey Neyman <stilor@att.net>
- Dump CT_LIBC_EXTRA_CC_ARGS: instead, treat CT_LIBC_EXTRA_CFLAGS as
arguments to CC (or they are not applied to .S, for example).
Combine them with multi_flags and CT_TARGET_CFLAGS in proper order.
- Analyze thus combined flags to determine --with-fp/--without-fp.
Don't need to check CT_ARCH_FLOAT - it is reflected in
CT_TARGET_CFLAGS anyway. Check more soft/hard float options defined
on different architectures.
- Drop checking for endianness flags: they are not reflected in
configure arguments in any way, and they're already present in CFLAGS
(either via multi_flags or via CT_TARGET_CFLAGS). Besides,
CT_ARCH_ENDIAN_OPT was actually called CT_ARCH_ENDIAN_CFLAG, so this
was a no-op anyway.
Signed-off-by: Alexey Neyman <stilor@att.net>
Install startfiles for libc variants into the most specific combination
(suffixed sysroot, if applicable + suffixed multi-os dir, if
applicable). Install headers once in every suffixed sysroot (although it
seems that GCC picks up headers from top-level sysroot, GCC manual
claims that sysroot suffix affects headers search path).
In uClibc, this requires a better sanitization of the directory: it
creates symlinks from {sysroot}/usr/lib/{multi_os_dir} to
{sysroot}/lib/{multi_os_dir} and to do so, it counts the number of path
components in the libdir. This breaks if one of such components is `..'
- symlinks contain an extra `../..' then. Since such sanitization had to
be implemented anyway, use it in other places to print more sensible
directory names.
Also, fix the description of configure --host/--target per musl's
configure help message (and its actual code).
Signed-off-by: Alexey Neyman <stilor@att.net>
On some arches (e.g. MIPS) the options like -mabi do not work if
specified more than once (see the comment in 100-gcc.sh). Therefore,
we need to determine which of the options produced by <arch>.sh can
be passed to multilib builds and which must be removed (i.e., which
options vary among the multilibs).
This presents a chicken-and-egg problem. GCC developers, in their
infinite wisdom, do not allow arbitrary multilib specification to be
supplied to GCC's configure. Instead, the target (and sometimes some
extra options) determine the set of multilibs - which may include
different CPUs, different ABIs, different endianness, different FPUs,
different floating-point ABIs, ... That is, we don't know which parts
vary until we build GCC and ask it.
So, the solution implemented here is:
- For multilib builds, start with empty CT_ARCH_TARGET_CFLAGS/LDFLAGS.
- For multilib builds, require core pass 1. Pass 1 does not build any
target binaries, so at that point, our target options have not been
used yet.
- Provide an API to modify the environment variables for the steps that
follow the current one.
- As a part of multilib-related housekeeping, determine the variable
part of multilibs and filter out these options; pass the rest into
CT_TARGET_CFLAGS/LDFLAGS.
This still does not handle extra dependencies between GCC options (like
-ma implying -mcpu=X -mtune=Y, etc.) but I feel that would complicate
matters too much. Let's leave this until there's a compelling case for
it.
Also, query GCC's sysroot suffix for targets that use it (SuperH,
for example) - the default multilib may not work if the command line
specifies the default option explicitly (%sysroot_suffix_spec is not
aware of multilib defaults).
Signed-off-by: Alexey Neyman <stilor@att.net>
Rather then building the manuals and locales for each multilib target, only
build the manuals on the last multilib target.
If you are not building a multilib toolchain, then the first libc build will
be the last.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
GCC makes the distinction between:
multilib (-print-multi-lib) and
multilib-os (--print-multi-os-directory)
as the GCC library and GCC sysroot library paths, respecitively.
Use this to build libc into the correct locations, the same
applies to the dummy libc.so
Changed by Alexey Neyman: restore missing CT_EndStep.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
The previous patch added the function 'CT_DoMultilibTarget()' to
scripts/build/arch/*.sh.
This patch calls the common function to (currently) get just the target
tuple for the current multilib target.
This patch was originally by: Cody P Schafer
Changed by Alexey Neyman: first, try `gcc -print-multiarch`. If it is
supported, use whatever it reports. Otherwise, fall back to our
guesswork. Move "i486" quirk into glibc.sh, as it is specific to glibc
(e.g. uclibc will need i386, which is what GCC reports).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
If a multilib configuration contains an endianness option, the
${endian_extra} is set to, for example, 'mb' (note, no dash!). It is
then added to CFLAGS, resulting in bogus flags like 'mb -mb'. But it is
not even needed, as ${extra_flags} already contains the very same
option!
Found by experimenting with multilibs with different endianness on SH,
which still didn't work, but that's another story...
Signed-off-by: Alexey Neyman <stilor@att.net>
GLIBC 2.23 dropped support for pre-v9 SPARC in pthreads. Pass host
triplet with s/sparc/sparcv9/ replacement for 2.23.
Signed-off-by: Alexey Neyman <stilor@att.net>
In do_libc_backend_once:
```
# Also, if those two are missing, iconv build breaks
extra_config+=( --disable-debug --disable-sanity-checks )
```
But in do_libc_locales we only add ```--disable-debug```.
This change adds ```--disable-sanity-checks``` to do_libc_locales to
mirror this, as I've seen iconv break this way.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
No point in calling an empty function. Must be left over from the
glibc/eglibc split up... then re-merge.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Since external add-ons were removed in 2.17, and we only support >=
2.18, this support is no longer needed.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Move crosstool-ng hook functions to be in the normal locations.
This commit has no functional changes.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates the build scripts to match the new usage of
CT_GetCustom from the previous change.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
.. they're needed for the RPC generation in glibc
on both Cygwin and MinGW-w64.
Neither are built on GNU/Linux and iconv is not
built on Darwin.
Two patches for gettext are needed, one so that
-O0 works and one so that static builds can be
made.
They can take a good while to build, so if not
needed for_host or for_build then they are not
built.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
glibc-2.17 and above no longer have external addons or ports.
So if we are => 2.17, don't even think about trying to mess with ports
or addons.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit adds support for the avr-libc C library.
According to the project page at http://www.nongnu.org/avr-libc , the
avr-libc package provides a subset of the standard C library for Atmel
AVR 8-bit RISC microcontrollers. In addition, the library provides the
basic startup code needed by most applications.
Support for this library in crosstool-ng is only enabled for the AVR
8-bit target.
The avr-libc manual and most distributions build the AVR 8-bit gcc
toolchain with the "avr" (non-canonical) target.
Some experimentation also led to the conclusion that other (canonical)
targets are not very well supported, so we force the "avr" target for
crosstool-ng as well.
The manual also recommends building avr-libc after the final gcc build.
To accomplish this with crosstool-ng, a new do_libc_post_cc step is
added, in which currently only avr-libc performs its build, and is a
no-op for the other libc options.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
Glibc actually does create a build executable. It's under sunrpc and it's
called cross-rpcgen. It uses gettext, so if that's not available in a standard
place on your system (for example if you're using Mac OS X and Homebrew), then
you are all out of luck.
Signed-off-by: Lawrence D'Anna <larry@elder-gods.org>
Prirotize http downloads before ftp downloads.
By having http download first, those using proxy will work with the
current download mechnism.
This tells me that that mechnism needs to be updated.
(proxy support and/or kconfig toggles)
closes#3
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
glibc versions that don't support --with-pkgversion or --with-bugurl
will cause a harmless:
====================
configure: WARNING: unrecognized options: --with-bugurl...`
====================
If it's set, use it, if it's a recognized option.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As posted on http://www.eglibc.org/
====================
EGLIBC is no longer developed and such goals are now being addressed
directly in GLIBC.
====================
I'm not interested in maintaining build support for unsupported
software.
Older branches of crosstool-ng continue to have eglibc support.
If you find issues with older branches, I'm always open to pull
requests.
Removing eglibc also frees up glibc cleanup and build optimization.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
