Remove the global linker search path, as it can cause spurious build
failures. If a library with the same name as a system library is in the
process of being written to the directory in the global search path, and
the linker may try to read the partially-written built one instead of the
system one. We already use full paths to libraries for target builds,
do the same for host builds. Also remove the normalize library
functions, they are no longer necessary.
Test: m -j checkbuild
Bug: 31393456
Change-Id: If9fc631e111f568c700fd73e103445c30d7e9d11
These are all either recently unused due to the removal of CFLAGS/etc,
or have been exported by Soong and are no longer necessary.
Change-Id: I5930d43fda21acc8202b3d8ea010fbefb6ae4cf1
Host native tests have been getting installed into
out/host/linux-x86/bin/..., but this pollutes the bin directory with a
lot of poorly named tests. Also, to support 32-bit and 64-bit tests, we
need to have different names with different suffixes. This causes
problems when tests expect to be named something specific (like gtest).
It's also convenient to store test data next to the test itself.
So with this change, native tests will be installed in
out/host/linux-x86/nativetest[64]/$(LOCAL_MODULE)/$(LOCAL_MODULE_STEM)
just like target tests get installed into /data/nativetest[64].
Implement this using a new NATIVE_TESTS class, which is like
EXECUTABLES, but sets up the install path differently, and configures
the rpath to load shared libraries with the proper relative path.
LOCAL_MODULE_RELATIVE_PATH can be used to control the directory name, it
will default to $(LOCAL_MODULE). This way multiple related tests can be
grouped together.
Target native tests also use NATIVE_TESTS now, but nothing should change
other than LOCAL_MODULE_RELATIVE_PATH can be used.
Change-Id: I535e42b1a6b21c5b8d6a580aa2f944d2be35e27d
At the beginning of every build, Soong has exported its version of these
variables, and has been ensuring that when sorted, the result is the
same. So these variables all have the same flags of the Soong ones, but
may be in different orders. We don't believe any of the remaining order
differences matter. As we remove the Make definitions, the exported
Soong variables will take over.
This only removes lines that change one of these variables:
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_CROSS_GLOBAL_LDFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]HOST_GLOBAL_CPPFLAGS
[2ND_][CLANG_]HOST_GLOBAL_LDFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CONLYFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_CPPFLAGS
[2ND_][CLANG_]TARGET_GLOBAL_LDFLAGS
Many other variables are unnecessary now too, but those will be removed
in another change. For those we can ensure the build.ninja file does not
change, but we expect it to change here due to the ordering differences.
Change-Id: I0bd0778706d02ee27b2784dd8dc6b2c71d37bd3a
We never use it for host modules, and all the target configurations use
the same linker argument. This matches Soong.
Change-Id: Ibcba9a4ce340c7a12306d1fee620a04027c0e292
These have all been strictly checked by Soong, so the values currently
match. Just remove them so that the make variables exported by Soong
will take over.
This also removes some of the GCC reconfiguration, since we haven't
implemented that in Soong. If it becomes useful in the future, we'll
implement it there.
Some things like TARGET_TOOCHAIN_ROOT can nearly be removed, but are
used before the Soong-exported make_vars.mk is loaded. In that case,
added to the clang cflags, so it can be removed once the cflags are
removed.
Others, like LLVM_PREBUILTS_VERSION are loaded even earlier -- in
envsetup.sh before we've even configured Soong. So for now, keep the
Make definition, and continue ensuring it's the same as the Soong
version.
Change-Id: I554b27062ac43610828a8c06d640d919a2dc21ca
Soong uses the copy of `ar` in the OSX SDK instead of the wrapper in
/usr/bin/ar. /usr/bin/ar appears to be a thin wrapper that looks up the
current SDK and passes execution to it. Soong does this so that it can
actually set up a dependency on the tool.
Change-Id: Ia4e4fbe3287539933fa98a1354c3ccee91f4d552
We've been including the system libc++ headers even if we're building
against our version of libc++. Stop doing that, and only add the headers
to our path if we're using the system libraries.
If nothing is specified, on recent OSX versions, libc++ is the default
c++ library instead of libstdc++. We've been explicitly including the
libc++ headers on all versions, but that breaks old versions. Force us
over to libc++, since the system libstdc++ does not support C++11, and
libc++ is still supported on our oldest version (10.8).
Change-Id: I1fccee8da0f425e10ccc9d3247ed40664eb6ada0
When a shared object is rebuilt, all dependent libraries and
executables are rebuilt. Such rebuild is unnecessary when there
is no interface change. With this patch, .toc files will be
generated for all .so files. The rule which generates .toc files
has ninja's restat=1 and .toc files are not changed ninja won't
rebuild dependent targets.
Performance:
$ m && touch bionic/libc/stdio/stdio.c && time m
Before: 1m03s (2563 targets)
After: 21s (90 targets)
Bug: 24597504
Change-Id: Ia5dd950273d143f4e99eee8bef7478f1a94cd138
Normally the binaries use the exsiting $ORIGIN/../lib[64] with binaries
in the bin subdirectory;
For historical reason the binaries in the SDK package don't have a bin
subdirectory. This workaround enables them to work in the existing SDK
directory structure.
Bug: 21301578
Change-Id: Ibebfbfb8b30e81e7bbaf13a21bb205f3f0282d24
(cherry-pick from commit 4fe7bfd373)
Add the build options to support the most recent versions of XCode and
add 10.9 to the list of OS X SDKs which the AOSP code can be built with.
Based on patch from https://groups.google.com/d/msg/android-building/kePgJmYBUdM/0C_d1OZflvcJ
Change-Id: I97ffe45d3c54a095952a4ac6accb938623b8fa1e
Signed-off-by: Al Sutton <al@funkyandroid.com>
We no longer need gcc for host builds, since those all run through clang. This
header include, however, triggers errors about SSE intrinsics by replacing
the more relevant include dirs that we should be using.
Change-Id: I26a949f0109de8e6e2d1f09cb8127be927549cc4
This change basically ported our target multilib to the host side.
It supports 2 host build modes: x86 and x86_64 multilib build.
For now you need to set "BUILD_HOST_64bit=true" to switch to x86_64
multilib build. Later we'll default to x86_64 build and have a flag
to force 32-bit only build, which may be needed by SDK build.
In host module definition, like in target ones, you can use the
following
LOCAL variables to set up multilib configuration:
LOCAL_MULTILIB: can be "both", "first", "32" or "64".
It also supports the same set of arch or 32-vs-64 specific LOCAL
variables.
By default, it builds only for the first arch.
To keep path compatibility, in x86_64 build files are still output to
out/host/linux-x86; Both 32-bit and 64-bit executables are in
out/host/linux-86/bin;
In x86_64 build 32-bit shared libraries are installed to
out/host/linux-x86/lib32
and 64-bit shared libraries are installed to out/host/linux-x86/lib;
32-bit object files are output to out/host/linux-x86/obj32 and 64-bit
object files
are output to out/host/linux-x86/obj.
Bug: 13751317
Change-Id: I6044f83b7db369a33e05209e8c588eb6dc83409f
This lays the groundwork for making builds hermetic on Darwin as well.
That will be fixed in a future patch.
bug 13435344
Change-Id: Iae82d0b9efad0598d682ff5fd4daa737aa607866
Mac's linker doesn't support --start-group and --end-group; it scans
libraries repeatedly even without these options, so it's not necessary.
Change-Id: If22527e75470f7fa9452dc33efe4d40a60d0919a
1. Use prebuilts/gcc/darwin-x86/host/i686-apple-darwin-4.2.1
See https://android-review.googlesource.com/#/c/46223/
2. Rewrite logic dealing with mac_sdk_version to support all
MacOSX SDK 10.6, 10.7 and 10.8. Note that since
ad2342375963c2468849c1f83a97158383db6511 emulator no longer
depends on 10.6 to build. Since the lowest SDK among intersection
of the "available" and the "supported" SDKs is picked, add a
new variable MAC_SDK_VERSION for developer really want to overwrite
it. MAC_SDK_VERSION still has to be one of the supported, though.
3. Improve mac_sdk_path detection to deal with case where Xcode
*dmg is mounted only, not installed at /Applications.
4. Now we can retire BUILD_MAC_SDK_EXPERIMENTAL
Change-Id: I83e463556a857d527710f766de0e19e1b576151f
Bug: 6754632
So the warning won't show up when you run lunch.
Now the warning only shows when you do a clean build.
Change-Id: I7876da783f059d390f0072df37d3ab0291589eb7
Recover variable build_mac_version which is removed on
commit 644dc16 and added on commit 9ce06f1.
Without this, ranlib libSDL.a is executed on Lion which
causes build fail of emulator-arm.
Change-Id: I06144a288921f8f968ef457999398c1b9152d4aa
XCode 4.3 and later use a different location for SDKs. This check in
ensures the build checks for the new location as well as the old one.
Change-Id: I97884e5009f229f8b42e57a8feeb702b3a40a241
Signed-off-by: Al Sutton <al@funkyandroid.com>
