This refreshes the line numbers, removes any fuzz (which would make any
future forward ports easier) and standardizes the patch/file headers
(which makes them easier to read).
Signed-off-by: Alexey Neyman <stilor@att.net>
To avoid proliferation of versions, I suggest the following policy: the
oldest LTS release still receiving maintenance updates + the most recent
release for distributions that offer LTS releases.
For CentOS, this means CentOS7 and CentOS Stream 9 (since CentOS are all
"long-term support", this is just the oldest and the newest among
currently supported).
For Ubuntu, this means Ubuntu 18.04 (previous LTS are in "security fixes
only" mode) and Ubuntu 21.10. Recent Ubuntu attempts to be interactive
during the configuration of tzdata, required some additional setup.
In the common installation script, the logic for handling a
configured/built local directory breaks if `gmake` is detected as the
make binary; `make distclean` then fails inside the container because
not all systems have `gmake` symlink. Remove that attempt of a
workaround completely, just require that the host directory is clean.
Signed-off-by: Alexey Neyman <stilor@att.net>
Otherwise, it tries to link against libgcc_eh which is not available
until the final compiler (or previously, the pass-2 compiler) is built.
Signed-off-by: Alexey Neyman <stilor@att.net>
With libc_headers step before pass-1, there is no need to distinguish
pass-1 and pass-2; they are configured identically (note that with the
current configuration, core pass-2 is only used for win32 - hence, uses
build_libgcc=yes and mode=static).
Signed-off-by: Alexey Neyman <stilor@att.net>
After 557b9d4, libc_start_files and libc_main steps are performed one
after another. It doesn't make sense, especially since some of the libcs
(glibc, uClibc-ng) go to great lengths to first install start files in
the first step, libc_start_files, only to remove them immediately in the
second step, libc_main.
Current build steps also break in the xtensa newlib configurations, as
it needs to install the custom xtensa headers before building the libgcc
and after 557b9d4, the headers are not installed before libgcc is built
in pass-1.
Therefore, finish what 557b9d4 mentioned but did not do: move header
installation into a new step, libc_headers, and combine libc_start_files
and libc_main into a single step.
This also allows to combine the core pass-1/pass-2 steps, to be done in
a subsequent commit.
Signed-off-by: Alexey Neyman <stilor@att.net>
This fixes the x86_64-multilib-linux-uclibc,powerpc-unknown-elf canadian
cross example (which currently breaks because the gnulib example assumes
SIGSTKSZ is constant while recent libcs started defining it as a
sysconf(...) call.
Signed-off-by: Alexey Neyman <stilor@att.net>
This was originally an upgrade from 11.1 to 11.2 that fixed moxie-*
samples affected by PR sim/28302. GDB 11.2 landed independently on
master, so just remove 11.1 (one release per upstream branch, please, we
already have lots of version/architecture/host permutations to test).
Signed-off-by: Alexey Neyman <stilor@att.net>
Starting with GDB9, the release number is only two numbers (with the
last being patchlevel). Therefore, keep two numbers for releases 8 and
below, but just a single number for 9 and up.
Signed-off-by: Alexey Neyman <stilor@att.net>
Starting with GDB10, it requires support for std::future<> in the
compiler. Such support has not been available on some architectures
until GCC9 (see PR 64735). I haven't determined the exact list of
affected architectures, so decided to make it a broad dependency: for
GDB10+, you need GCC9+.
Signed-off-by: Alexey Neyman <stilor@att.net>
Restrict kernel to 5.11 and below (support for this arch has been
dropped in 5.12); rename the sample to match its name as printed by
`ct-ng show-tuple` (otherwise, `make saveconfig` does not update the
sample's configuration).
Signed-off-by: Alexey Neyman <stilor@att.net>
*-moxie*: DTC_VERBOSE is a wobbler, it depends on whether dtc is enabled
on the host machine (if dtc is installed, DTC defaults to 'n' and hence
prevents DTC_VERBOSE from appearing at all). Remove the option from
config file so that its value reverts to the default.
xtensa-fsf-elf: mark configuration obsolete so that it can use GDB 8.1
(it uses custom sources and needs to select the version therein)
Signed-off-by: Alexey Neyman <stilor@att.net>
Run samples through upgrade and fix accumulated breakages:
*-centos6-*: After 2.12.2 retirement, the samples selected most recent
glibc (2.34) which also forced kernels 3.2+. Revert to 2.12.1 and
2.6.32.71, respectively. Interestingly, 2.12.1 was marked as being used
in CentOS6, but the samples selected 2.12.2. Anyway, CentOS6 is EOL now
and glibc 2.12 is going to be marked obsolete, and retired soon.
arc-*: Make TARGET_VENDOR match the sample's name; otherwise `ct-ng
saveconfig` places the config file into a different location.
Fix 'savedefconfig' which was not saving the configuration file version
(CT_VCHECK was set to 'load' after CT_LoadConfig call).
Signed-off-by: Alexey Neyman <stilor@att.net>
... and the code dependent on them, after the latest wave of obsolete
package removals. This concludes the glorious history of the original
uClibc (non-NG) with lots of kludges removed.
There was a choice here, whether to call the resulting libc "uClibc" or
"uClibc-ng". I opted in favor of giving uClibc-ng the recognition it
deserves, although it had some ripple effect in the ct-ng code.
Signed-off-by: Alexey Neyman <stilor@att.net>
GCC 4.8 and its prerequisites have been removed by 04dce680, 41d4583a
and e4221734; as a result, 4.8-based version of gcc-oracle became
unbuildable (no valid versions for the prerequisites).
Update the samples to use 4.9.4; which however fails to build on a modern
host GCC. Build fix backported to gcc-4.9 and gcc-5 versions.
Fix binutils-oracle build with host GCC11.
Signed-off-by: Alexey Neyman <stilor@att.net>
Copied patches from glibc version 2.34, they still apply clean and I
assume they still are relevant.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
[cp add __convert_scm_timestamps patch]
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Forward port patches from gdb-11.1, as they still apply clean, hence
still assumed to be relevant.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
Fetch in various patches from binutils-2_37-branch upstream.
The most vital change is the
0012-pr28391-strip-objcopy-preserve-dates-a-cannot-set-time.patch which
allows building large upstream projects like Qt WebEngine without need
100k's of file descriptors open.
Signed-off-by: Hans-Christian Noren Egtvedt <hegtvedt@cisco.com>
Versions before 2.26 got removed in fa992b41, together with
CT_BINUTILS_2_23_or_later.
Remove reference to this variable
Signed-off-by: Norbert Lange <nolange79@gmail.com>
Now that we have a 2-pass build it is no longer necessary to disable
-Werror in glibc.
This partially reverts commits 6ca5f91f ("Disable -Werror for GLIBC for
all ARCH for GCC11."), 215432d3 ("config/libc: Extend glibc 2.32
workaround to include sparc") and 645ee124 ("glibc: Don't build with
-Werror for powerpc64+glibc-2.32").
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Per https://github.com/crosstool-ng/crosstool-ng/issues/808 build static
libgcc in the first pass which lets us skip the second one. Building
mingw-w64 requires header files in order to build C++ support so mingw
builds core pass 2. This could probably be cleaned up by splitting
libc_start_files into a separate libc_header step. But for now having
core 2 for mingw-w64 and core 1 for the other libcs will have to do.
Anything that previously selected CC_CORE_PASSES_NEEDED now selects
CC_CORE_PASS_1_NEEDED. The same goes for CC_CORE_PASS_2_NEEDED with the
exception of mingw-w64.
Fixes#808Fixes#217
Signed-off-by: Chris Packham <judge.packham@gmail.com>
BSD patch does not support --no-backup-if-mismatch. When we detect patch
check that it supports the option we use.
Fixes: #1577
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Run `ct-ng updatetools` to pick up the latest config.{sub,guess} from
upstream. This picks up support for some new architectures (e.g.
loongarch) and some new variants of existing ones. There is some
refactoring that makes the diff a bit larger but it's fairly easy to
follow.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
Add a comment that is visible when the python3.4 prerequisite is not met
so that users can tell why they can't select a newer glibc version.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
As of Linux v5.3 rsync is used as part of the build process. Add Linux
5.3 as a milestone, configure detection of rsync and a dependency on
rsync for Linux 5.3 and newer. Add a comment in so that users can tell
why they can't select a newer version.
Fixes#1628
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The CI builds currently seem unhappy on macOS when we build make
ourselves. Install GNU make via brew so that we don't have to build it
ourselves.
Signed-off-by: Chris Packham <judge.packham@gmail.com>
The patch in question was first introduced in [1] as a copy-paste
from OpenEmbedded [2], where it seems to exist on the first ever SVN commit.
Later it was removed from OE in [3] on switching to Binutils 2.25.
It's not clear why it was introduced in the first place and why it
got removed later. But given in OE/Yocto it was missing since 2015
and never was reverted, I guess it is not strictly necessary
at least with recent Binutils. So it's an extra patch which adds
questionable value. Moreover it gets in the way if one wants to
merge a couple of separate toolchains like little- & big-enadian
so that "bin" & "lib" folder contain all the binaries and libs
simultaneously. W/ that patch in place ldscripts won't co-exist,
but instead the latest set of scripts will override all the rest.
And in case of aforementioned example w/ merged little- &
big-endian toolchains BE ldscripts will override LE ones leading
to a funny behavior: on linking w/o explicitly set endianess
(via "-EL" or "-EB") default linker scripts won't match the GCC driver
used:
------------------------------->8---------------------------
$ arc-elf32-gcc test.c -Wl,-marcv2elfx
...
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: .../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/lib/crt0.o: compiled for a little endian system and target is big endian
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: failed to merge target specific data of file .../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/lib/crt0.o
.../bin/../lib/gcc/arc-snps-elf/11.2.0/../../../../arc-snps-elf/bin/ld: .../bin/../lib/gcc/arc-snps-elf/11.2.0/crti.o: compiled for a little endian system and target is big endian
...
------------------------------->8---------------------------
[1] cfbcdd3786
[2] 4b46c1f6e8
[3] 3c7fe424f8
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
These days old v5 ABI is not that relevant as it used to be back in
2015 when ncurses 6.x was added to CT-NG.
And now we see say target "gdb" relying on "libncurses.so.5",
while up-to-date Buildroot provides "libncurses.so" & "libncurses.so.6":
--------------------------->8-------------------------
$ ldd /bin/gdb
libncurses.so.5 => not found
libstdc++.so.6 => /lib/libstdc++.so.6 (0x20022000)
libm.so.6 => /lib/libm.so.6 (0x2017c000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201ba000)
libc.so.6 => /lib/libc.so.6 (0x201c8000)
/lib/ld-linux-arc.so.2 (0x20000000)
--------------------------->8-------------------------
Switching to a default (v6 ABI) by default. And...
--------------------------->8-------------------------
$ ldd /bin/gdb
libncurses.so.6 => /usr/lib/libncurses.so.6 (0x20022000)
libstdc++.so.6 => /lib/libstdc++.so.6 (0x20054000)
libm.so.6 => /lib/libm.so.6 (0x201ae000)
libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x201ec000)
libc.so.6 => /lib/libc.so.6 (0x201fa000)
/lib/ld-linux-arc.so.2 (0x20000000)
--------------------------->8-------------------------
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
