... when using musl to compile strace.
Also, honor CT_TARGET_CFLAGS in scripts compiling target libs/binaries.
Signed-off-by: Alexey Neyman <stilor@att.net>
- 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>
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>
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>
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>
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>
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>
