... it is not needed to install headers and causes build failures
in more than one setup (cygwin, macos).
Signed-off-by: Alexey Neyman <stilor@att.net>
... when building native GDB/gdbserver.
Suggested by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
If GDB is turned off, the script will not be even sourced. Otherwise,
if GDB checkbox is set but none of the cross/native/gdbserver are
selected, debug.sh gives a bogus error message.
Signed-off-by: Alexey Neyman <stilor@att.net>
CT_TARGET is composed as "${CT_ARCH}${CT_ARCH_SUFFIX}", so CT_TARGET may
become something like "armv7", for example. This is used by the configure
script to set the "CPU" variable in the Makefile, leading to a commad line
containing
-DTARGET_armv7 -DTARGET_CPU="armv7"
In this case the compilation of elf2flt.c fails with "Don't know how to
support your CPU architecture??". Passsing "CPU=${CT_ARCH}" in the make
command line overrides the configured value and solves the problem.
Signed-off-by: Carlos Santos <casantos@datacom.ind.br>
- Allow user to specify configure arguments to pass through to host/target
ncurses.
- Checkbox for --disable-database
- String option for --with-fallbacks
Signed-off-by: Alexey Neyman <stilor@att.net>
instead of 'make oldconfig' and responding 'y'. This avoids 'Broken pipe'
errors in the log, as well as selects default setting for all options not
explicitly set.
This requires a small fix in the old uClibc. Won't have to maintain that fix
for long though :)
Signed-off-by: Alexey Neyman <stilor@att.net>
This serves two purposes:
- installs its manpage
- installs headers, without them it does not make sense to install a
static library
Unfortunately, there's no way to select shared-only build of DUMA.
Hence, disable selection for static library.
Also, allow user to select whether to use stock or ct-ng's wrapper.
Signed-off-by: Alexey Neyman <stilor@att.net>
Rather than requiring them of a certain version, detect if they are present
(and have sufficient version) and select an appropriate companion tool
otherwise. The reason is that, for example, most recent gettext requires
automake 1.15, but the newest available CentOS has 1.13. Hence, the option
to "upgrade your system" does not apply, and the warning comment above
the companion tools is rather scary.
With this approach, it will work out of the box - either by using the host's
tools, or by building them as needed. Note that the user can still change
the setting in the config.
While there, propagate the new version checking macro to awk/bash/host binutils,
and switch from --with-foo=xxx to officially blessed FOO=xxx: the latter
does not require checking for bogus values (i.e., --with-foo, --without-foo)
and AC_PROG_* macros recognize the corresponding settings without further
modifications. For now, I kept --with-foo=, if only to complain and steer
people to the new way. To be cleaned up after a release.
Signed-off-by: Alexey Neyman <stilor@att.net>
So that uClibc config can be matched to Buildroot's expectations via
the menu, without the need for a saved config.
Signed-off-by: Alexey Neyman <stilor@att.net>
There are some useful tools such as widl, gendef, genidl ... etc.
provided by mingw-w64 and do not waste the developers' works.
Signed-off-by: Li-Hang Lin <lihang.lin@gmail.com>
The correct solution was checked in to strace GIT; will be part of the
next release. Backport patch to 4.10..4.15, and remove the workaround
from 500-strace.sh. Versions 4.9 and older should build fine even
without the workaround (they would be picking up wrong definitions,
but they need different patch and I don't feel like spending any time
on these versions).
Signed-off-by: Alexey Neyman <stilor@att.net>
And never had, at least since newlib 1.17 (first version added to
crosstool-ng). Apparently, copy-pasted from glibc.sh.
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>
Make them configurable, default to y when build!=host (i.e.
canadian or cross-native) because we don't know what libraries the host
will provide. GLIBC, as previously, selects them explicitly.
Signed-off-by: Alexey Neyman <stilor@att.net>
This is needed for callbacks that use that directory to look inside
GCC internal directories, e.g. moving the libraries. This broke
when I made libexpat for target honor ${CT_SHARED_LIBS}.
Signed-off-by: Alexey Neyman <stilor@att.net>
- No new releases in almost 10 year.
- No public bug tracker or VCS.
- No responses from maintainer over sent patches.
RIP, dmalloc.
Signed-off-by: Alexey Neyman <stilor@att.net>
This follows the trend set by 1*.sh scripts that configure ISL, GMP,
MPFR, CLooG, etc. Building with shared libraries presents all kinds
of problems:
- The shared libraries need to be installed into ${CT_PREFIX_DIR}.
- The binaries linked against companion libs need to have proper
RPATH, or they're looking for shared libs in
.build/${CT_PREFIX}/buildtools/lib.
- All libraries must agree as to whether they're built shared,
static, or both. Otherwise, gettext tries to link in static libncurses.a
into a shared library and fails (since libncurses was compiled without
the -fPIC switch and hence contains relocations that cannot be handled
in a shared library).
So this fixes the current mess. If we decide to re-enable building
the companion libs shared, we should probably make this dependent on
a separate suboption of CT_STATIC_TOOLCHAIN.
Add a config loosely based on one reported in the issue 274.
Signed-off-by: Alexey Neyman <stilor@att.net>
There are two separate issues with gdb configure usage:
1) inspecting build system libraries while cross-compiling;
2) preferring a shared library over static one.
The first usage issue is described and fixed now.
The second issue was described but the notes were removed
for some reason. This patch restores those notes.
Suggested-by: Alexey Neyman <stilor@att.net>
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
In that case, CT_GetCustom just creates a symlink to the original.
In that case, 'cp -a <path> .' gives an error and 'cp -a <path> <newdir>'
creates <newdir> as a symlink (which will then run the build inside
the shared directory, .build/src/<package>).
Signed-off-by: Alexey Neyman <stilor@att.net>
Current build passes {CFLAGS,LDFLAGS}_FOR_HOST - which breaks canadian cross
(e.g. tried building for x86_64-unknown-linux-uclibc host). This dates
back to the days of yore when CFLAGS were set directly in the do_gcc_core_backend
(and that function is used as the final gcc's backend).
do_gcc_core_backend is now passed with CFLAGS/LDFLAGS to use, so let
the pass-1/pass-2/final-for-build steps pass the appropriate flags.
Signed-off-by: Alexey Neyman <stilor@att.net>
To build uClibc correctly we need correct endianness selected in the
crosstool-NG. Xtensa cores may be little- or big-endian, but this
property is static. The toolchain knows the core endianness and doesn't
need options to select it.
Enable ARCH_SUPPORTS_BOTH_ENDIAN and select LE by default. Specify empty
CT_ARCH_ENDIAN_CFLAG so that -m{big,little}-endian don't get added to
the TARGET_CFLAGS, as it's not supported by gcc. Specify empty
CT_ARCH_ENDIAN_LDFLAG so that -EB/-EL don't get added to the
TARGET_LDFLAGS as they are ignored. Select big-endian in the example
xtensa-unknown-linux-uclibc configuration.
This fixes uClibc toolchain build for little-endian cores.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Allow selection of make/m4/... version. Support imports of new versions
via addToolVersion.sh. Import newest versions of the companion tools.
One non-trivial change is the handling of make versions. Existing code
was not handling make companion tool as described (see the previous
commit). However, since most modern systems have make 4.x, that previous
commit made crosstool-ng always build make as a companion tool.
This traces back to the commit dd15c93 from 2014. That commit's log message
says that actually it was 3.81 which broke the build for certain component
(it was originally breaking eglibc, but I noticed it was breaking current
glibc on powerpc64), and introduced an option to force using 3.81 by
"components that really need it". It looks like in 2.5 years we haven't
seen any such components that really need make 3.81, and (given that make
has already had a few releases since 3.81) we're unlikely to see them
in the future.
Hence, the configure check is changed from "exactly 3.81" to "3.81 or newer".
In its current form, configure will accept make 3.80+, and will not require
make as a companion tool for 3.81+. We might want to bump the latter check
to even newer version given the claim from dd15c93. Killed
COMP_TOOLS_make_3_81_NEEDED.
Anyway, I retained 3.81 just in case; ditto for m4 1.14.3, autoconf 2.65
and automake 1.11.1.
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>
Commit 6f8e89cb5c broke that option.
Since ${make} points to /usr/bin/make, making the symlink from gmake
to /usr/bin/make is obviously the wrong decision. gmake should link to
our (old-versioned) self-built make.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
1. Check if anything was installed outside sysroot; on some [baremetal only?]
configurations GCC doesn't install anything to ${CT_PREFIX_DIR}/${CT_TARGET}/lib.
2. We need to create <sysroot>/lib/<multilib> if it doesn't exist
(MUSL only installs in <sysroot>/usr/lib).
3. Do not move the linker scripts; elf2flt expects to find them
in gcc's dir, not sysroot.
Signed-off-by: Alexey Neyman <stilor@att.net>
1.0.15 only kept a single LINUXTHREADS option, and renamed it, making it
no longer option-compatible with uClibc.
The option for "1.0.14 or later" version of uClibc-ng is not currently
used; rename it to "1.0.15 or later" and use it to handle newer
uClibc-ng's linuxthreads.
m68k happens to be the only sample using linuxthreads.
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>
On the stage "core gcc pass-2" the following layout is created:
1) buildtools/bin/TARGET-{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip}
2) buildtools/TARGET/bin/{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip}
3) x-tools/TARGET/bin/TARGET-{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip}
4) x-tools/TARGET/TARGET/bin{ar,as,elf2flt,flthdr,ld,ld.bfd,ranlib,strip}
where both (1) and (2) are symlinks to (3). This effectively renders
core pass-2 gcc with elf2flt linker unusable.
Related elf2flt discussion:
https://github.com/crosstool-ng/crosstool-ng/pull/443
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
mingw-gcc searches for include and libs in <sysroot>/mingw
directory while non-mingw-gcc uses <sysroot>/usr. This patch
sets an appropriate prefix for target companion libs.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
This patch fixes libexpat detection for gdb-native and
gdb-cross static builds.
For gdb-native build configure should not touch system
/usr/{lib,include} directories while looking for libexpat.
To fix this we pass --without-libexpat-prefix flag
to configure script.
For gdb-cross build configure is allowed to investigate
system /usr/{lib,include} directories, but it does not
hurt to disable this behavior. In this case configure
falls back to -lexpat, which works as expected.
For more info:
http://marc.info/?l=gnulib-bug&m=129660262901148&w=2
Signed-off-by: Kirill Smirnov <kirill.k.smirnov@gmail.com>
This change adds native ldd and ldconfig utils to sysroot.
For glibc just 'make install' installs everything including utils.
For uclibc there exists a separate goal 'install_utils'. Make it.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
It turns out that core GCC on binfmt architectures (m68k, for example)
cannot produce the final executable (looks for ld.real in the wrong
place). Need to wait for the final gcc to become available.
Signed-off-by: Alexey Neyman <stilor@att.net>
'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>
Create a separate 'libc_backend_once', install headers into a
subdirectory (different sets of headers are installed for 32- and 64-bit
architectures), and create a symlink for the dynamic linker location
expected by GCC.
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>
In preparation for multilib support, use the same "backend" model that
is already employed by glibc and musl.
Also, the verbosity setting descriptions were swapped. V=2 is actually
less verbose than V=1: V=1 prints full commands, while V=2 prints 'CC
<file> <defines>'.
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>
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>
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>
i[34567]86-*-gnux32 is not a valid tuple.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <ray.donnelly@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
This code was abstracted out of Cody P Schafer's multilib patch.
It doesn't seem right having architecture dependent code in a
specific libc implementation script. So this patch breaks it out into
scripts/build/arch/<arch>.sh in a function:
multilib_target_to_build="$(CT_DoArchMultilibTarget 'multi_flags'
'target-in')"
Note that this function gets called on each multilib variant with
different sets of compiler flags supplied in 'multi_flags'. The caller
will first filter the flags so that there is no conflicting flags (e.g.,
no '-m32 -m64') supplied.
Changed by Alexey Neyman:
- make option analysis check specific option rather than match global
options string as a whole. Moreover, old code did not handle multiple
options in the same multilib, e.g. '-m64 -mlittle'.
- fixed substitutions in powerpc.sh (*le variants did not match the
pattern in the shell parameter expansion)
- make s390.sh actually apply the flags it gathered from the options.
- straighten the spaghetti in x86.sh by setting two flags, arch & abi.
Also, do not depend on "gnu" being the last part - we can have
'*-uclibcx32', for example.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Signed-off-by: Ray Donnelly <ray.donnelly@gmail.com>
Signed-off-by: Alexey Neyman <stilor@att.net>
Written by Bryan Hundven.
Modified by Alexey Neyman to actually add the option to gcc.in.
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>
By default, it is 'auto' - which means, it is enabled if there are
multilibs directories detected in the installation location for libgcc.
Thus, it is not detected for pass-1 GCC: the installation location is
empty at this point.
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>
By default, sparc64-*-linux is configured with -mcpu=v9. However,
according to https://sourceware.org/ml/libc-alpha/2005-12/msg00027.html:
"There is no Linux sparc64 port that runs on non-UltraSPARC-I+ ISA
CPUs."
v9 is such a "non-UltraSPARC-I+ ISA CPU", so it makes no sense to
default to v9 when targetting Linux.
Change the default to ultrasparc, even though it can suboptimally
schedule instructions for newer SPARC CPUs. See the pending patch:
https://patchwork.ozlabs.org/patch/409424/
Signed-off-by: Alexey Neyman <stilor@att.net>
Previous fix for cross-gdb broke powerpc-unknown_nofpu-linux-gnu which
uses an old GDB (6.8a). That GDB's configure chokes on $CC values with
multiple consecutive spaces; see the comment in 300-gdb.sh.
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>
GDB's configure mishandles the libexpat.{so,a} libraries when it is
given -static in CFLAGS AND --with-libexpat-prefix in configure's args:
it checks for <prefix>/lib/libexpat.so and finding that, attempts to
link it as `gcc -static .. conftest.c <prefix>/lib/libexpat.so`; this
obviously fails (.so cannot be statically linked), so configure assumes
libexpat is unusable. Thus, --with-libexpat-prefix is dangerous and
should be avoided; instead, configure should find the libraries via the
supplied CC/LD definitions.
Pass CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET and LDFLAGS_FOR_TARGET to
gcc configure in do_gcc_core_backend as they may be used to build
libstdc++ for bare-metal target.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
This commit moves the do_libc_configure function to do_libc_backend and
switches do_libc_start_files and do_libc_final to call do_libc_backend.
The major reason for the rewrite is that musl => 1.1.13 has had it's own
build system rewritten and can now build out-of-tree.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
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>
As crosstools-ng only support GCC >= 4.8 we do not need libelf for gcc. GCC dropped this dependency with 4.6.
Signed-off-by: Matthias Weisser <m.weisser.m@gmail.com>
elf2flt is now hosted on github here:
https://github.com/uclinux-dev/elf2flt
But, until arm support is upstream, we'll switch to Waldemar Brodkorb
version of elf2flt.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In a5057713a0
...I forgot to add a line continuation at the break in the 'if'
statement.
Reported-by: asavah <asavah@avh.od.ua>
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
I was noticing that $extra_user_env was inconsistently used in
100-gcc.sh. I don't feel comfortable having just any make flag or
environment variable passed to make from a config file. If a specific
option needs to be passed to make for gcc, then a specific kconfig
option should be added for that make flag/option/env.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
The two gcc backend functions are getting very close to being duplicated
code. To help in the process of merging the two backends, this change
syncronizes the two functions so they are easier to diff.
This commit has no functional changes.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
If destdir was / and prefix began with /
then we would attempt to install libelf
to a path beginning with // which is a
UNC path on Cygwin. This is generally
incorrect.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
On Windows a build failure can be triggered during the
build of the static iconv if a dynamic iconv is already
present:
There's a circular dependency between libiconv and gettext
which (on a system with a dynamic gettext (and thus iconv)
installed in the system prefix) causes a failure to build
iconv.exe statically if it is built with nls ..
.. Which needs gettext
.. which depends on libiconv
.. so libtool finds a dynamically linked libgettext.la
.. and therefore presents ld with the dll import library
libiconv.dll.a when linking iconv.exe
.. as well as the static libiconv.a that it has just built!
.. leading to multiply defined symbols from iconv.
Therefore, we build it without nls. If it later turns out
that we need it to be built with nls, then I will have to
build it in two passes (common practice when bootstrapping
GNU/Linux distros, MSYS2 and probably Cygwin and Homebrew).
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Build shared builds for host unless CT_STATIC_TOOLCHAIN.
In all other situations, build statically, as before.
It is necessary that the static/shared-ness of expat matches
that of gettext on Cygwin/MinGW-w64 as they can't be linked
together if they don't match, so we follow the same logic.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
If CT_BINUTILS_FOR_TARGET_IBERTY is set, then it seems that we also must
set `--enable-install-libiberty` for configure to pickup that it needs
to be installed.
This closes#302
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>
This option allowed you to use a custom headers directory/tarball to use
in your sysroot.
Not to be confused with using a custom source, that option is the
preferred method.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Since CUSTOM_LOCATION_ROOT_DIR was removed from config/global/paths.in
in commit c499ccb, xtensa should depend only on it's
ARCH_XTENSA_CUSTOM_OVERLAY_LOCATION.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
If building a static toolchain, the ldflags option passed to
do_binutils_backend is overridden when we set `LDFLAGS=-all-static`.
We should pass `LDFLAGS=${ldflags} -all-static` in this case.
This fixes#297
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
In commit: 74d555b2
A regex in a parameter subsitution replaces a '#' hash symbol, but it is
not made literal '\#', so from the hash to the end of the line is a
comment.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Instead of checking if thread support is enabled during the build, move
the check to kconfig-time. Since if threading support is not availble,
libgomp should not be available either.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Because >= gcc-5.x does not require cloog, it should not be forced on
the command line arguments for configure if graphite is enabled.
Make CLooG optionally added, if it is needed (aka: <= gcc-4.9).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Now that versions of gcc that required PPL are no longer supported
( >= gcc-4.5.x AND <= gcc-4.7.x )
...we no longer require PPL or CLooG/PPL.
This commit:
* Removes PPL
* Removes CLooG/PPL
* Updates the documentation
* Updates build script for CLooG and GCC
* Removes PPL and CLooG/PPL from scripts/addToolVersion.sh and
scripts/showSamples.sh
* Adds ISL to scripts/addToolVersion.sh and scripts/showSamples.sh
I know that sounds like a lot for one commit, but it was all kind of
inter-tangled.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per #222, in crosstool-NG >= 1.23.0, we will only support:
[upstream supported gcc versions] - 1
As of this writing, these versions are:
* 5.2.0
* 4.9.3
* 4.8.5 (the -1, since development on 4.8.x is now closed)
I plan to keep 4.8.5 around because of some architectures having issues
with over-optimization or just faulty optimization in the 4.9.x and
possibly newer versions.
I also cleaned up a requirement for glibc to depend on >= gcc-4.6.x for
>= glibc-2.20, but since the lowest gcc we support after this change is
>= 4.8.5, this condition can go away.
Patches for older gcc versions are removed in the next commit.
This closes#222
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
When building from:
{git,http}://sourceware.org/git/binutils-gdb.git
and setting BINUTILS_CUSTOM or GDB_CUSTOM, they could be the same
source.
These config options should not affect normal released versions.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per the change notes of GCC-6:
https://gcc.gnu.org/gcc-6/changes.html
and conversations I've had with the buildroot folks, there is no need
to support sh5/sh64.
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>
This commit removes ncurses-5.9 and adds 6.0.
I also provide the stable patch updates in patches/ncurses/6.0.
I have also added an experimental toggle for enabling the new ABI
support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Now that expat/curses have migrated into separate script, no need for
do_debug_gdb_parts() and need_gdb_src checks.
Signed-off-by: Alexey Neyman <stilor@att.net>
Currently, builds for build and target (matching the current
implementation). Need to add building for host for canadian crosses.
TIC_PATH is removed - configure in ncurses searches $PATH, so it finds
'tic' in buildtools anyway. Arguably unneeded code for MacOS also
removed, with a FIXME comment for validation by someone using MacOS.
Signed-off-by: Alexey Neyman <stilor@att.net>
Currently, only libelf has a for-target step - but it generalizes
the step to hook other libraries into this step.
Signed-off-by: Alexey Neyman <stilor@att.net>
The Xtensa processor architecture is a configurable, extensible,
and synthesizable 32-bit RISC processor core. Processor and SOC vendors
can select from various processor options and even create customized
instructions in addition to a base ISA to tailor the processor for
a particular application.
Because of the configurability, the build process requires one additional
step for gcc, binutils, and gdb to update the default configuration.
These configurations are packed into an 'overlay' tar image, and are
simply untarred on top of the default configuration during the build.
Signed-off-by: Max Filippov <jcmvbkbc@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>
I've added the .config files to contrib/uClibc-defconfigs from buildroot
to use as default configs if they are not provided in the sample.
If a particular architecture really needs an option set, it should be
either updated in the manange_uClibc_config function in
scripts/build/libc/uClibc.sh or a custom ${uclibc_name}.config should be
added to the sample (usually via `ct-ng saveconfig`).
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit updates uClibc to use the new CT_Kconfig options from the
previous commit. The older sed method of sanity checking the uClibc
.config was error prone and clumsy.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
mpfr.org has been less then reliable, so lets make gnu.org the primary
instead of the secondary source.
This closes#250
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This commit removes blackfin support.
I'm open to re-adding blackfin after crosstool-1.23.0 is released, but
it is currently too difficult to port forward to newer versions of gcc
and uclibc.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Some architectures, like arc and blackfin set CROSS_COMPILE to a default
if it is not set on the command-line.
Since we are building the cross-compiler, we need to ALWAYS set
CROSS_COMPILE, since building/checking headers is done after the GCC
PASS1 step.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
This change, as per #222, reduces the number of supported releases of
gcc to the latest branch releases.
I noticed while doing this work that gcc-4.5.4 was never added, so I
moved patches for gcc-4.5.3 to 4.5.4 and updated the
bfin-unknown-linux-uclibc example. Also, 120-siginfo.patch was fixed
upstream in the 4.5.4 release, so this patch is omitted.
I also bumped the avr sample to 4.9.3 from 4.9.2.
With the addition of gcc-5.x, the gcc release team now releases the
major.minor.0 versions, while updates to the branch are available in
svn/git. We'll address that when we get to issue #219. This change just
removes CC_GCC_5_1 and moves CC_GCC_5_2 to CC_GCC_5, and removes
CC_GCC_5_1_or_later and moves CC_GCC_5_2_or_later to CC_GCC_5_or_later.
This is the first of two part changes, as mentioned in #222.
This change is slated for release in 1.22.0. The next change will be
slated for 1.23.0, and will limit gcc versions to what is on
https://gcc.gnu.org under "Release Series and Status", which is
currently 4.9.3 and 5.2.0, although I will also support the previous
supported version. In this example that would be 4.8.5.
Last, but not least, this change also retires AVR32 support.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Having *.la in the installation directory breaks ltrace: in ltrace,
libtool somehow considers libsupc++ to be an "accessory library" and
does not add -lsupc++ to the link flags. Neither Ubuntu, nor RedHat
include *.la files into their packages for libstdc++.
Signed-off-by: Alexey Neyman <stilor@att.net>
- New configurations:
- CC_GCC_TARGET_FINAL:
Use the default targets "all" and "install" for the final compiler for
bare metal.
- Adding parameter "build_step" to function do_gcc_core_backend:
do_gcc_core_backend is used for the core compiler and in case of bare metal
for the final compiler, too. To have better control over the parameters for
the final compiler "build_step" is used.
- Used for proper logging.
- Use CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY or CT_CC_GCC_EXTRA_CONFIG_ARRAY.
- If CT_CC_GCC_TARGET_FINAL is set and the final compiler is build then the
make targets for the final compiler are used ("all", "install").
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
CT_CC_GCC_HAS_LIBQUADMATH and CT_CC_GCC_LIBQUADMATH (--en/disable-libssp,
--en/disable-libquadmath, --en/disable-libquadmath-support) from function
do_gcc_backend.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
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>
Configure for for core GCC did not use Core gcc extra config.
Use now config variable CT_CC_GCC_CORE_EXTRA_CONFIG_ARRAY.
Signed-off-by: Jasmin Jessich <jasmin@anw.at>
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>
This commit adds support for the Atmel AVR 8-bit RISC architecture.
This is the first 8-bit architecture to be added to crosstool-ng so the
configuration options for 8-bit architectures are added here as well.
gcc has had support for AVR for quite a while, at least since the 4.3
series for the currently popular ATmega microcontroler series.
The AVR architecture only supports bare-metal toolchains.
gcc for the AVR 8-bit architecture, usually referred to as avr-gcc, is
commonly used in conjunction with the avr-libc library which provides
additional resources for the Atmel AVR 8-bit microcontrollers.
avr-gcc can also be found as a supported package in some recent Linux
distributions.
This commit also closes#66
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
This option is old. GCC 4.3.x old. It isn't supported anymore, and just
confuses me. I'm not planning to support 4.3.x, or really anything older
then 4.7. So this option is gone to the wind.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Acked-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
This commit updates gcc's test suite to use the new config options.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Update 300-gdb.sh to use the new config options.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
Update 100-gcc.sh to use the new config option names.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@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>
This commit moves gcc.sh to 100-gcc.sh to accomodate for other
cross-compilers that crosstool-ng might be able to build.
The first, to come soon, is llvm/clang.
Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
Reviewed-by: Bryan Hundven <bryanhundven@gmail.com>
Reviewed-by: Yann Diorcet <diorcetyann@gmail.com>
The argument will prevent the prefix path from being added as an include path while building mingw. Having the prefix as an include path might cause all kinds of weird issues if prefix directory also exists on the build machine.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
Added new functions to support changes in prefix and required vendor tuple for new versions of mingw.
Tested and verified with mingw version 2.0.7, 3.3.0 and 4.0-rc3.
Signed-off-by: Nils Petter Eftedal <nilspetter@eftedal.org>
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>
Without this canadion cross builds create invalid symlinks:
When the code in do_cc_core_backend is called there is no
${CT_TARGET}-gcc in the install directory. Therefore ext is empty and
we create a link to ${CT_TARGET}-gcc. The final compiler
step then installs ${CT_TARGET}-gcc.exe and creates a working
${CT_TARGET}-cc.exe symlink but we still keep the invalid link
as well.
Signed-off-by: Johannes Pfau <johannespfau@gmail.com>
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>
We had following problem: We're building a toolchain with an old glibc
version for compatibility with old Linux distributions (glibc 2.9). This
version requires make < 4 to build. However, the configure script of
glibc looks for make in the order "gnumake", "gmake" and "make". So when
"gmake" is available in the system (which is the case on Gentoo Linux
per default, unfortunately), then configure finds the system gmake 4.1
instead of the ct-ng make 3.82.
This patch adds an option to install a symlink so that 'gmake' is also
available in the old version when building toolchains.
Signed-off-by: Bernhard Walle <bernhard@bwalle.de>
Canadian Cross compile for baremetal fails with error;
checking for the value of EOF... configure: error: computing EOF failed
which is due to libstdc++ configure not being able to find stdio.h
Having all modes of the core compiler copyheaders from CT_HEADERS_DIR
(in combination with previous patch for newlib to add a do_libc_start_files
function to copy into the CT_HEADERS_DIR) resolves this.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Require access to newlibs headers in gcc.sh, matching other libc components.
Resolves issue with headers not found.
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Currently, the obsolete RPC headers are only installed for eglibc,
but glibc has the same /deficiency/, so install the obsolete RPC
for both.
Signed-off-by: Jérôme BARDON <bardon.pro@gmail.com>
Signed-off-by: David Holsgrove <david.holsgrove@xilinx.com>
Yes, I missed the backslash which messed up the linaro stuff.
The more I look at this code, I feel it needs to be refactored a bit. So
I'll come back to this in the future and clean it up.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
It's not my day.
linaro_version is a filter. If it is not a linaro toolchain, it will
just be CT_{CC,GDB}_VERSION. If it is a linaro toolchain, CT_{CC,GDB}_VERSION
will be prefixed with 'linaro-' and will not match linaro_version, as
linaro_version will just have the part after 'linaro-'.
This *really* fixes the issue :sigh:
Thanks again to @elsonwei for being right the first time!
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
linaro_version and linaro_series are defined but not set if we are not
configured for linaro builds.
Therefore we need to default them to "" (null string).
As reported by @elsonwei
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
