This required some rework of the libc selection, as moxiebox is a layer on
top of another libc - newlib.
Also, moxiebox'es host VM (`sandbox`) needs a libcrypto on the host. We will
not have it if we're cross-compiling a canadian cross. Fortunately, all moxiebox
needs from libcrypto is SHA256, and it already includes a standalone implementation
of SHA256 in its runtime. Provide a little wrapper that allows moxiebox use
that implementation for the host binary, too.
Also, automate collecting/printing the list of all packages in a given category
(e.g. LIBC or COMP_TOOLS), generate a list of all Kconfig symbols for a given
category.
Signed-off-by: Alexey Neyman <stilor@att.net>
This sample works well for building the open-source first stage
bootloader for the SiFive U540 device (and similar):
https://github.com/sifive/freedom-u540-c000-bootloader
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
This sample works well for the SiFive U540 device (and similar).
Thanks to Jim Wilson <jimw@sifive.com> for his review, discovering
several bugs (now fixed).
Cc: Jim Wilson <jimw@sifive.com>
Signed-off-by: Paul Walmsley <paul.walmsley@sifive.com>
There's no point in keeping samples which are in its essense
just a sub-set of multilib toolchain.
But still we'd like to cover quite unusual but really existing
case - ARC750, i.e. ARC700 with MMU but without so-called
atomic instructions (LLOCK/SCOND). To support this HW variation
we need:
1) Compile all target binaries without "-matomics" or even
better "-mno-atomics" so that's even future-proof
(as we may decide to enable "-matomics" by default for Linux
targets which is a recommented setup).
2) Configure libc such that it uses Linux-kernel-assisted implementation
of atomic operation via "arc_usr_cmpxchg" syscall,
see https://cgit.uclibc-ng.org/cgi/cgit/uclibc-ng.git/commit/?id=b985fa069187e4c5a7ee84213d9fbead2f219ce5
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
- Glibc configure args and tuple need adjustment on SuperH
- Only allow "both endian" and "with CPU" for unspecified arch
variant. May reconsider endianness (was breaking things before
adjusting glibc tuple)
- Retire non-multilib sample, it should be a subset of the
multilib one now.
Signed-off-by: Alexey Neyman <stilor@att.net>
1. On SuperH, configuring GCC with explicit variant of the CPU
(like "sh4") limits the default set of multilibs to just that CPU
and requires --with-multilib-list to change. Allow for "unspecified"
variant, so that we can defer to GCC to determine the list.
2. Support toolchains with both endiannesses at the same time.
3. Add a SuperH/newlib sample
4. Add more flags processing for uClibc
Signed-off-by: Alexey Neyman <stilor@att.net>
E.g., only include minor/major of the Linux kernel into the kconfig
symbol. In the future, to be defined by all packages, but for now
matches the current versioning in the packages.
Signed-off-by: Alexey Neyman <stilor@att.net>
Must have eabi suffix for GCC to accept it. Also:
- We only have one glibc now, no need to account for eglibc.
- Rename aarch64 samples, eabi suffix does not apply to them
(and ct-ng saveconfig was saving them into a different directory).
Fixes#772.
Signed-off-by: Alexey Neyman <stilor@att.net>
The line CT_GETTEXT=y is remains from canadian sample. This cross
sample does not need it.
Signed-off-by: Kirill K. Smirnov <kirill.k.smirnov@gmail.com>
- Update .gitignore, do not place .gitignore into directories installed
in bulk
- Remove executable permissions and shebangs from the scripts that are
supposed to be invoked only via ct-ng frontent; prepend them with $(bash).
Despite what showSamples.sh said, it already has some bashisms.
- Remove --with autotools-dev and override dh_update_autotools_config
to avoid having config.{sub,guess} clobbered with older versions
- Install bash completion where Debian (now) expects it
- Update man page to use .\" as the comment delimiter, instead of
undefined macro (."); also, minor text edits.
- Install kconfig.mk without execute permission.
- Remove shell wrappers from 170-localedef-fix-trampoline.patch, we
do not use that for applying patches
- Revoke execute permissions on 210-expat.sh
- Get flags from dpkg-buildflags if available
Signed-off-by: Alexey Neyman <stilor@att.net>
Allow cross-gdb and gdbserver. This requires removal of an explicit
check that disables gdbserver on android. However, the comment above
that check refers to exec_elf.h, which has been removed since API level
19. It builds fine with current selection of the sample (21). Only
build-tested, hope someone can give it a try and report back.
We can fine tune the check for GDB but I'll leave it for now.
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>
(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>
GCC does not distinguish the resulting binary by the CFLAGS (e.g. based
on which -march= was given). This means, while it will use the right
libraries for linking, at runtime they are all going to request the same
ld.so path and load the libraries from the same default path.
Signed-off-by: Alexey Neyman <stilor@att.net>
Hence, it is better to enforce via config rules: elf2flt does not
play nice with ld wrapper, when both ld.bfd and ld.gold are present.
Limit the choices to just 'ld.bfd' for flat-format architectures.
Signed-off-by: Alexey Neyman <stilor@att.net>
... that exhibited the issue with elf2flt configuration. Original reported
did not provide the config, and did not respond.
Signed-off-by: Alexey Neyman <stilor@att.net>
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>
So that 'ct-ng saveconfig' works properly.
Also, run it through 'ct-ng saveconfig' so that default options are removed.
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>
This enables the resulting toolchaing to be used to build a canadian
cross to x86_64-pc-linux-gnu target. Unmark that sample as broken,
it now builds successfully.
It is likely that it is affected by issue #483, too - I see the
resulting gcc executable has a DLL dependency on libiconv-2.dll,
which is only installed into .build/.../buildtools. This will be
investigated/fixed separately.
Signed-off-by: Alexey Neyman <stilor@att.net>
Put xtensa core name to the tuple vendor string (without any overlay the
default core is 'fsf') and rename sample directory accordingly.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
Add -mlongcalls and -mtext-section-literals to target CFLAGS. Target
libraries built with these flags have great call range, useful for linux
applications.
Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
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>
No threads (uclibc/libpthread does not compile on ARMv8); no C++ (libitm
depends on pthreads), no GDB/DUMA (depend on threads).
Signed-off-by: Alexey Neyman <stilor@att.net>
Based on the following samples:
- x86_64-unknown-linux-gnu (-m64/-m32/-mx32)
- powerpc64-unknown-linux-gnu (-m64/-m32)
- mipsel-unknown-linux-gnu (-mabi={32,n32,64})
- sh4-unknown-linux-gnu (-m4/-m4a)
- x86_64-unknown-linux-uclibc (-m64/-m32)
- mips64el-unknown-linux-uclibc (-mabi={32,n32,64})
New samples:
- sparc64-multilib-linux-gnu (-m64/-m32)
- sh4-multilib-linux-uclibc (-m4/-m4a/-m3)
- x86_64-multilib-linux-musl (-m64/-m32)
Notably missing is arm-unknown-linux-gnu (aprofile): GLIBC does not
compile in one of the variants in its multilib set (-march=armv4t
-mthumb) due to missing atomic ops implementation.
Signed-off-by: Alexey Neyman <stilor@att.net>
This change adds a powerpc64le-unknown-linux-gnu sample that can be used
to quickly create a little-endian tool-chain for powerpc64
architecture. This sample is based on the earlier work done by "Yann
E. MORIN" to add support for powerpc64 tool chain and implementing the
power64-unknown-linux-gnu sample. The existing sample however generates
a big-endian tool chain by default.
Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
With avr-libc 2.0.0 released, we no longer need to force gcc 4.9.x for
the avr toolchain. So, remove the gcc version constraint and allow it to
follow the default gcc version. There is also no need to force companion
libraries' versions anymore.
The 'experimental' flag was also removed from the description as it
seems to be following upstream development now.
This sample has been build tested on Arch Linux and Ubuntu 14.04 hosts.
Signed-off-by: Erico Nunes <nunes.erico@gmail.com>
I couldn't get this sample to build. I tried rolling ct-ng back to 1.22
and back to the commit that introduced it, to no avail. Not sure if it
ever built on my machine.
The first problem is the failure to build binutils/gold because of the
missing <pthread.h> in mingw. However, even if CT_BINUTILS_GOLD_THREADS
option is unset, the build dies in configure of the pass-1 of the core CC.
The config.log states that it failed to link with libmpfr.a, which has
a lot of undefined references to symbols like '__imp___iob_func'.
Googling shows that these symbols are some dark Cygwin/MinGW magic and I
do not have the knowledge of these arcana. Let some other MinGWizard fix
it another day.
Signed-off-by: Alexey Neyman <stilor@att.net>
There is invalid assembly in dmalloc for PowerPC. The issue is that
'stw' expects a memory operand, and =g constraint allows both registers
and memory. Newer GCC tends to choose register even at -O0, resulting in
invalid assembly. Instead, force a register constraint in 'mflr' and let
GCC decide if it wants to store it into memory at all.
Reported this upstream.
Signed-off-by: Alexey Neyman <stilor@att.net>
With the upcoming release of 1.22.0, mingw-w64 is still in an
experimental state, and is not considered to be fully supported yet.
This change should be reverted after the release.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
As per 4be766254d, mips64 is not longer
experimental, and as such, the samples should not need it enabled.
Signed-off-by: Bryan Hundven <bryanhundven@gmail.com>
Drop ARCH_ARCH/ARCH_TUNE where it is overridden by ARCH_CPU. Also, same
updates as in the previous batch for architectures with
!ARCH_EXCLUSIVE_WITH_CPU (i.e. where there is no need to drop
ARCH_CPU/ARCH_TUNE).
Signed-off-by: Alexey Neyman <stilor@att.net>
