... 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>
... 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>
For that, make CT_BUILD_TOP_DIR a non-settable config option (so that it is
recursively expanded with CT_HOST/CT_TARGET). Use a common prefix, with
same default as for regular sample build.
Use showConfig.sh to determine host toolchain path (for canadian crosses)
and build directory to be removed.
Remove LIBC_SYSROOT_ARG (unused).
Signed-off-by: Alexey Neyman <stilor@att.net>
Makes them sorted out by host, and removes the need for similar hack in
samples.mk.
Change how canadian crosses are named: using `=' character resulted in
Glibc build failure.
Move loading config into a common function, CT_LoadConfig.
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
Similarly to FOR_HOST; recent change in 100-gcc.sh that switched
FOR_HOST->FOR_BUILD broke simple cross configurations on macos.
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>
For a cross-compiler, we only need to make the 'build tools' for the
'build'. We also build the 'build tools' for the 'host' when building a
cross-canadian toolchain.
Closes#430
Signed-off-by: Bryan Hundven <bryanhundven@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>
