Commit Graph

12 Commits

Author SHA1 Message Date
Alexey Neyman
ca45a8f9ab Add -D__GLIBC__ to target CFLAGS
... 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>
2017-09-30 18:47:35 -07:00
Alexey Neyman
567277099a Fix the references to old config variables
Signed-off-by: Alexey Neyman <stilor@att.net>
2017-07-08 10:57:56 -07:00
Alexey Neyman
d91277e377 Add zlib as a companion lib
with version 1.2.11.

Signed-off-by: Alexey Neyman <stilor@att.net>
2017-02-05 14:26:02 -08:00
Alexey Neyman
7186e39f32 Run all configure scripts using ${CONFIG_SHELL}
... as its help message says in menuconfig.

Signed-off-by: Alexey Neyman <stilor@att.net>
2017-01-25 00:06:28 -08:00
Alexey Neyman
3dbb576c17 Make companion libs static.
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>
2016-12-11 00:46:06 -08:00
Alexey Neyman
f5a375e407 Merge pull request #443 from KirillSmirnov/gdb-native
debug/gdb: properly link with expat
2016-12-05 18:24:05 -08:00
Alexey Neyman
488b27f58b Partially revert 6f8e89cb5c.
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>
2016-11-20 23:50:17 -08:00
Kirill K. Smirnov
5fd69f7652 complibs: let mingw-gcc find target companion libs
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>
2016-09-10 03:35:53 +03:00
Ray Donnelly
24d17220a1 libelf: Cygwin fix for UNC paths
If destdir was / and prefix began with /
then we would attempt to install libelf
to a path beginning with // which is a
UNC path on Cygwin. This is generally
incorrect.

Signed-off-by: Ray Donnelly <mingw.android@gmail.com>
2016-01-03 15:53:09 +00:00
Bryan Hundven
6f8e89cb5c consistency: Use exported variables of required tools
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>
2015-11-17 02:48:09 -08:00
Yann Diorcet
b43fdf40f1 scripts: add BUILD/HOST extra cflags/ldflags
On some hosts, and for certain toolchains (eg. toolchain targetting
the upcoming Darwin), it may be necessary to pass arbitrary CFLAGS
and/or LDFLAGS when building the components.

And necessary infrastructure:
  - EXTRA_{CFLAGS,LDFLAGS}_FOR_{BUILD,HOST} as config options
  - pass those extra flags to components

Fix-up a slight typo in elf2flt at the same time (misnamed cflags).

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <d24043276c9243a35421.1353077450@macbook-smorlat.local>
Patchwork-Id: 199645
2012-11-16 15:25:57 +01:00
Yann Diorcet (diorcet yann
0be070e5b7 complibs: introduce generic multi-complibs infrastructure
Use the same method as companion tools for providing generic and
extendable companion libs.

Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
Message-Id: <515c5c4635d99ebe4877.1353074410@macbook-smorlat.local>
Patchwork-Id: 199613
2012-11-16 14:59:27 +01:00