Synopsys' DesignWare ARC Processors are a family of 32-bit CPUs
that SoC designers can optimize for a wide range of uses,
from deeply embedded to high-performance host applications in a variety
of market segments.
Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com>
- Incompatible function type for ifunc alias
- Multiple statements macro expansion in strftime
- if_nametoindex size checking
Signed-off-by: Alexey Neyman <stilor@att.net>
... in the corresponding /lib directory. Mingw-w64 installs it to /bin,
so multiple variants in a multilib configuration override each other.
Signed-off-by: Alexey Neyman <stilor@att.net>
Also, build containers with --no-cache: distributions like ArchLinux
retire their packages very quickly, need to always use up-to-date
package databases.
Signed-off-by: Alexey Neyman <stilor@att.net>
... which now defaults to --enable-mpers=yes, which attempts to
invoke aarch64-*-gcc with -m32 and fails.
Signed-off-by: Alexey Neyman <stilor@att.net>
curl and wget are needed as a build dependency so that the auto configuration will see them and set the relevant configuration options. Otherwise, we end up with a ct-ng that can't download anything.
However, curl and wget are not strict runtime dependencies, and we don't need both, so list them as Recommends: curl | wget for the binary package.
As we support CentOS, for example, we have a problem there
automake: warnings are treated as errors
kconfig/Makefile.am:26: warning: compiling 'lxdialog/checklist.c' in subdir requires 'AM_PROG_CC_C_O' in
'configure.ac'
autoreconf: automake failed with exit status: 1
Automake does not allow us to place the hooks before its generated actions,
and does not allow us to check MAKECMDGOALS, and does not support a mechanism
for disabling make install (such as noinst_SUBDIRS, requested a few times
on automake mailing list). The only way I could preserve the current behavior
is to have a GNUmakefile wrapper that will convert MAKECMDGOAL into a variable
unknown to automake - which seems too convoluted a solution for the problem
being solved.
Hence the approach is to not override anything for --enable-local. It is now
fully handled by selecting different values for CT_xxx_DIR in ct-ng.in; but
at the build-system level, all the variables remain the same. We just don't
support 'make install' in that case anymore; but the ct-ng in the working
copy can be used after a regular 'make' (or 'make all').
Help message for --enable-local updated accordingly.
Signed-off-by: Alexey Neyman <stilor@att.net>
